dev_17.0.6

Nniny7[ELF][AArch64] Relax zero TLSLE add to nop (#204286)

70612fb7创建于 6月22日历史提交

文件	最后提交记录	最后更新时间
AArch64.cpp	[ELF][AArch64] Relax zero TLSLE add to nop (#204286) Optimize AArch64 local-exec TLS relocation handling by replacing a self-add R_AARCH64_TLSLE_ADD_TPREL_HI12 instruction with nop when the high 12 bits are zero. The optimization is disabled by --no-relax and avoids non-equivalent forms such as non-self-adds and 32-bit destination registers.	1 个月前
AMDGPU.cpp	Move from llvm::makeArrayRef to ArrayRef deduction guides - last part This is a follow-up to https://reviews.llvm.org/D140896, split into several parts as it touches a lot of files. Differential Revision: https://reviews.llvm.org/D141298	3 年前
ARM.cpp	[LLD][ELF] Cortex-M Security Extensions (CMSE) Support This commit provides linker support for Cortex-M Security Extensions (CMSE). The specification for this feature can be found in ARM v8-M Security Extensions: Requirements on Development Tools. The linker synthesizes a security gateway veneer in a special section; .gnu.sgstubs, when it finds non-local symbols __acle_se_<entry> and <entry>, defined relative to the same text section and having the same address. The address of <entry> is retargeted to the starting address of the linker-synthesized security gateway veneer in section .gnu.sgstubs. In summary, the linker translates input: .text entry: __acle_se_entry: [entry_code] into: .section .gnu.sgstubs entry: SG B.W __acle_se_entry .text __acle_se_entry: [entry_code] If addresses of __acle_se_<entry> and <entry> are not equal, the linker considers that <entry> already defines a secure gateway veneer so does not synthesize one. If --out-implib=<out.lib> is specified, the linker writes the list of secure gateway veneers into a CMSE import library <out.lib>. The CMSE import library will have 3 sections: .symtab, .strtab, .shstrtab. For every secure gateway veneer <entry> at address <addr>, .symtab contains a SHN_ABS symbol <entry> with value <addr>. If --in-implib=<in.lib> is specified, the linker reads the existing CMSE import library <in.lib> and preserves the entry function addresses in the resulting executable and new import library. Reviewed By: MaskRay, peter.smith Differential Revision: https://reviews.llvm.org/D139092	2 年前
AVR.cpp	[lld][ELF] Support relocations R_AVR_LO8_LDI_GS/R_AVR_HI8_LDI_GS Relocations R_AVR_LO8_LDI_GS/R_AVR_HI8_LDI_GS (indirect calls via function pointers) only cover range 128KiB. They are equivalent to R_AVR_LO8_LDI_PM/R_AVR_HI8_LDI_PM within this range. But for function addresses beyond this range, GNU-ld emits trampolines. And this patch implements corresponding thunks for them in lld. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D147364	3 年前
Hexagon.cpp	[ELF] Set DF_STATIC_TLS for AArch64/PPC32/PPC64	3 年前
LoongArch.cpp	[lld][LoongArch] Handle extreme code model relocs according to psABI v2.30 (#73387) psABI v2.30 requires the extreme code model instructions sequence (pcalau12i+addi.d+lu32i.d+lu52i.d) to be adjacent. See https://github.com/llvm/llvm-project/pull/71907 and https://github.com/loongson-community/discussions/issues/17 for details. (cherry picked from commit 38394a3d0b8b9a1fdc444bdebeba17a19250997d)	1 年前
MSP430.cpp	[ELF] Clean up headers. NFC	4 年前
Mips.cpp	[lld] LLVM_FALLTHROUGH => [[fallthrough]]. NFC With C++17 there is no Clang pedantic warning or MSVC C5051.	3 年前
MipsArchTree.cpp	[ELF] Remove ctx indirection. NFC Add LLVM_LIBRARY_VISIBILITY to remove unneeded GOT and unique_ptr indirection. We can move other global variables into ctx without indirection concern. In the long term we may consider passing Ctx as a parameter to various functions and eliminate global state as much as possible and then remove Ctx::reset.	3 年前
PPC.cpp	[PowerPC][lld] Account for additional X-Forms -> D-Form/DS-Forms load/stores when relaxing initial-exec to local-exec D153645 added additional X-Form load/stores that can be generated for TLS accesses. However, these added instructions have not been accounted for in lld. As a result, lld does not know how to handle them and cannot relax initial-exec to local-exec when the initial-exec sequence contains these additional load/stores. This patch aims to resolve https://github.com/llvm/llvm-project/issues/64424. Differential Revision: https://reviews.llvm.org/D158197 (cherry picked from commit 698b45aa902de4d30c798e8d6bd080c8e31bade8)	2 年前
PPC64.cpp	[ELF] Handle relocations in synthetic .eh_frame with a non-zero offset within the output section (#65966) When the .eh_frame section is placed at a non-zero offset within its output section, the relocation value within .eh_frame are computed incorrectly. We had similar issue in .ARM.exidx section and it has been fixed already in https://reviews.llvm.org/D148033. While applying the relocation using S+A-P, the value of P (the location of the relocation) is getting wrong. P is: P = SecAddr + rel.offset, But SecAddr points to the starting address of the outputsection rather than the starting address of the eh frame section within that output section. This issue affects all targets which generates .eh_frame section. Hence fixing in all the corresponding targets it affecting.	1 年前
PPCInsns.def	[LLD][PowerPC] Implement GOT to PC-Rel relaxation This patch implements the handling for the R_PPC64_PCREL_OPT relocation as well as the GOT relocation for the associated R_PPC64_GOT_PCREL34 relocation. On Power10 targets with PC-Relative addressing, the linker can relax GOT-relative accesses to PC-Relative under some conditions. Since the sequence consists of a prefixed load, followed by a non-prefixed access (load or store), the linker needs to replace the first instruction (as the replacement instruction will be prefixed). The compiler communicates to the linker that this optimization is safe by placing the two aforementioned relocations on the GOT load (of the address). The linker then does two things: - Convert the load from the got into a PC-Relative add to compute the address relative to the PC - Find the instruction referred to by the second relocation (R_PPC64_PCREL_OPT) and replace the first with the PC-Relative version of it It is important to synchronize the mapping from legacy memory instructions to their PC-Relative form. Hence, this patch adds a file to be included by both the compiler and the linker so they're always in agreement. Differential revision: https://reviews.llvm.org/D84360	5 年前
RISCV.cpp	[lld][ELF] Support relax R_LARCH_ALIGN (#78692) Refer to commit 6611d58f5bbc ("Relax R_RISCV_ALIGN"), we can relax R_LARCH_ALIGN by same way. Reuse SymbolAnchor, RISCVRelaxAux and initSymbolAnchors to simplify codes. As riscvFinalizeRelax is an arch-specific function, put it override on TargetInfo::finalizeRelax, so that LoongArch can override it, too. The flow of relax R_LARCH_ALIGN is almost consistent with RISCV. The difference is that LoongArch only has 4-bytes NOP and all executable insn is 4-bytes aligned. So LoongArch not need rewrite NOP sequence. Alignment maxBytesEmit parameter is supported in psABI v2.30. (cherry picked from commit 06a728f3feab876f9195738b5774e82dadc0f3a7) (cherry picked from commit 60a8ec3a35c722a9eb8298c215321b89d0faf5b5)	2 年前
SPARCV9.cpp	[ELF] Clean up headers. NFC	4 年前
Sw_64.cpp	[Sw64] Add Sw64 target support for lld	1 年前
X86.cpp	[ELF] Support TLS GD/LD relaxations for x86-32 -fno-plt For x86-32, {clang,gcc} -fno-plt uses call *___tls_get_addr@GOT(%reg) instead of call ___tls_get_addr@PLT. GD to IE/LE relaxations need to shift the offset by one while LD to LE relaxation needs to use a different code sequence. While here, fix some comments. Fix https://github.com/llvm/llvm-project/issues/59769 Differential Revision: https://reviews.llvm.org/D140813	3 年前
X86_64.cpp	[ELF] Handle relocations in synthetic .eh_frame with a non-zero offset within the output section (#65966) When the .eh_frame section is placed at a non-zero offset within its output section, the relocation value within .eh_frame are computed incorrectly. We had similar issue in .ARM.exidx section and it has been fixed already in https://reviews.llvm.org/D148033. While applying the relocation using S+A-P, the value of P (the location of the relocation) is getting wrong. P is: P = SecAddr + rel.offset, But SecAddr points to the starting address of the outputsection rather than the starting address of the eh frame section within that output section. This issue affects all targets which generates .eh_frame section. Hence fixing in all the corresponding targets it affecting.	1 年前