#
3041b16f |
| 10-May-2021 |
Sam Clegg <sbc@chromium.org> |
[WebAssembly] Add TLS data segment flag: WASM_SEG_FLAG_TLS
Previously the linker was relying solely on the name of the segment to imply TLS.
Differential Revision: https://reviews.llvm.org/D102202
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
#
3b8d2be5 |
| 27-Feb-2021 |
Sam Clegg <sbc@chromium.org> |
Reland: "[lld][WebAssembly] Initial support merging string data"
This change was originally landed in: 5000a1b4b9edeb9e994f2a5b36da8d48599bea49 It was reverted in: 061e071d8c9b98526f35cad55a918a4f16
Reland: "[lld][WebAssembly] Initial support merging string data"
This change was originally landed in: 5000a1b4b9edeb9e994f2a5b36da8d48599bea49 It was reverted in: 061e071d8c9b98526f35cad55a918a4f1615afd4
This change adds support for a new WASM_SEG_FLAG_STRINGS flag in the object format which works in a similar fashion to SHF_STRINGS in the ELF world.
Unlike the ELF linker this support is currently limited: - No support for SHF_MERGE (non-string merging) - Always do full tail merging ("lo" can be merged with "hello") - Only support single byte strings (p2align 0)
Like the ELF linker merging is only performed at `-O1` and above.
This fixes part of https://bugs.llvm.org/show_bug.cgi?id=48828, although crucially it doesn't not currently support debug sections because they are not represented by data segments (they are custom sections)
Differential Revision: https://reviews.llvm.org/D97657
show more ...
|
#
061e071d |
| 10-May-2021 |
Nico Weber <thakis@chromium.org> |
Revert "[lld][WebAssembly] Initial support merging string data"
This reverts commit 5000a1b4b9edeb9e994f2a5b36da8d48599bea49. Breaks tests, see https://reviews.llvm.org/D97657#2749151
Easily repros
Revert "[lld][WebAssembly] Initial support merging string data"
This reverts commit 5000a1b4b9edeb9e994f2a5b36da8d48599bea49. Breaks tests, see https://reviews.llvm.org/D97657#2749151
Easily repros locally with `ninja check-llvm-mc-webassembly`.
show more ...
|
#
5000a1b4 |
| 27-Feb-2021 |
Sam Clegg <sbc@chromium.org> |
[lld][WebAssembly] Initial support merging string data
This change adds support for a new WASM_SEG_FLAG_STRINGS flag in the object format which works in a similar fashion to SHF_STRINGS in the ELF w
[lld][WebAssembly] Initial support merging string data
This change adds support for a new WASM_SEG_FLAG_STRINGS flag in the object format which works in a similar fashion to SHF_STRINGS in the ELF world.
Unlike the ELF linker this support is currently limited: - No support for SHF_MERGE (non-string merging) - Always do full tail merging ("lo" can be merged with "hello") - Only support single byte strings (p2align 0)
Like the ELF linker merging is only performed at `-O1` and above.
This fixes part of https://bugs.llvm.org/show_bug.cgi?id=48828, although crucially it doesn't not currently support debug sections because they are not represented by data segments (they are custom sections)
Differential Revision: https://reviews.llvm.org/D97657
show more ...
|
#
b0ef2070 |
| 10-May-2021 |
Harald van Dijk <harald@gigawatt.nl> |
[X86] Fix position-independent TType encoding
The logic for x86_64 position-independent TType encodings was backwards, using 8 bytes where 4 were wanted and 4 where 8 were wanted. For regular x86_64
[X86] Fix position-independent TType encoding
The logic for x86_64 position-independent TType encodings was backwards, using 8 bytes where 4 were wanted and 4 where 8 were wanted. For regular x86_64, this was mostly harmless, exception tables are allowed to use 8-byte encodings even when it is not needed. For the large code model, and for X32, however, the generated exception tables were wrong. For the large code model, we cannot assume that the address will fit in 4 bytes. For X32, we cannot use 64-bit relocations.
Fixes PR50148.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D102132
show more ...
|
#
632ebc4a |
| 05-May-2021 |
Philipp Krones <philipp.krones@embecosm.com> |
[MC] Untangle MCContext and MCObjectFileInfo
This untangles the MCContext and the MCObjectFileInfo. There is a circular dependency between MCContext and MCObjectFileInfo. Currently this dependency a
[MC] Untangle MCContext and MCObjectFileInfo
This untangles the MCContext and the MCObjectFileInfo. There is a circular dependency between MCContext and MCObjectFileInfo. Currently this dependency also exists during construction: You can't contruct a MOFI without a MCContext without constructing the MCContext with a dummy version of that MOFI first. This removes this dependency during construction. In a perfect world, MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the MCContext, like other MC information. This is future work.
This also shifts/adds more information to the MCContext making it more available to the different targets. Namely:
- TargetTriple - ObjectFileType - SubtargetInfo
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D101462
show more ...
|
#
70c433a1 |
| 30-Apr-2021 |
Sidharth Baveja <sidharth.baveja@ibm.com> |
[XCOFF][AIX] Add Global Variables Directly to TOC for 32 bit AIX
Summary: This patch implements the backend implementation of adding global variables directly to the table of contents (TOC), rather
[XCOFF][AIX] Add Global Variables Directly to TOC for 32 bit AIX
Summary: This patch implements the backend implementation of adding global variables directly to the table of contents (TOC), rather than adding the address of the variable to the TOC. Currently, this patch will look for the "toc-data" attribute on symbols in the IR, and then add those symbols to the TOC. ATM, this is implemented for 32 bit AIX.
Reviewers: sfertile Differential Revision: https://reviews.llvm.org/D101178
show more ...
|
#
7049fbf9 |
| 29-Apr-2021 |
jasonliu <jasonliu.development@gmail.com> |
[XCOFF] Handle the case when personality routine is an alias
Summary: Personality routine could be an alias to another personality routine. Fix the situation when we compile the file that contains t
[XCOFF] Handle the case when personality routine is an alias
Summary: Personality routine could be an alias to another personality routine. Fix the situation when we compile the file that contains the personality routine and the file also have functions that need to refer to the personality routine.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D101401
show more ...
|
#
a6441191 |
| 29-Apr-2021 |
Sriraman Tallam <tmsriram@google.com> |
Basic block sections for functions with implicit-section-name attribute
Functions can have section names set via #pragma or section attributes, basic block sections should be correctly named for suc
Basic block sections for functions with implicit-section-name attribute
Functions can have section names set via #pragma or section attributes, basic block sections should be correctly named for such functions.
With #pragma, the expectation is that all functions in that file are placed in the same section in the final binary. Basic block sections should be correctly named with the unique flag set so that the final binary has all the basic blocks of the function in that named section. This patch fixes the bug by calling getExplictSectionGlobal when implicit-section-name attribute is set to make sure the function's basic blocks get the correct section name.
Differential Revision: https://reviews.llvm.org/D101311
show more ...
|
#
7a718e16 |
| 20-Apr-2021 |
Petr Hosek <phosek@google.com> |
[MC] Use COMDAT for LSDA only if IR comdat type is any
This fixed issue introduced in 16af97393346ad636298605930a8b503a55eb40a and 796feb61637c407aefcc0d462f24a1cc41f350d8.
Differential Revision: h
[MC] Use COMDAT for LSDA only if IR comdat type is any
This fixed issue introduced in 16af97393346ad636298605930a8b503a55eb40a and 796feb61637c407aefcc0d462f24a1cc41f350d8.
Differential Revision: https://reviews.llvm.org/D100909
show more ...
|
#
1756b2ad |
| 03-Mar-2021 |
Victor Huang <wei.huang@ibm.com> |
[AIX][TLS] Generate TLS variables in assembly files
This patch allows generating TLS variables in assembly files on AIX. Initialized and external uninitialized variables are generated with the .csec
[AIX][TLS] Generate TLS variables in assembly files
This patch allows generating TLS variables in assembly files on AIX. Initialized and external uninitialized variables are generated with the .csect pseudo-op and local uninitialized variables are generated with the .comm/.lcomm pseudo-ops. The patch also adds a check to explicitly say that TLS is not yet supported on AIX.
Reviewed by: daltenty, jasonliu, lei, nemanjai, sfertile Originally patched by: bsaleil Commandeered by: NeHuang
Differential Revision: https://reviews.llvm.org/D96184
show more ...
|
#
47c5576d |
| 27-Feb-2021 |
Fangrui Song <i@maskray.me> |
ELF: Create unique SHF_GNU_RETAIN sections for llvm.used global objects
If a global object is listed in `@llvm.used`, place it in a unique section with the `SHF_GNU_RETAIN` flag. The section is a GC
ELF: Create unique SHF_GNU_RETAIN sections for llvm.used global objects
If a global object is listed in `@llvm.used`, place it in a unique section with the `SHF_GNU_RETAIN` flag. The section is a GC root under `ld --gc-sections` with LLD>=13 or GNU ld>=2.36.
For front ends which do not expect to see multiple sections of the same name, consider emitting `@llvm.compiler.used` instead of `@llvm.used`.
SHF_GNU_RETAIN is restricted to ELFOSABI_GNU and ELFOSABI_FREEBSD in binutils. We don't do the restriction - see the rationale in D95749.
The integrated assembler has supported SHF_GNU_RETAIN since D95730. GNU as>=2.36 supports section flag 'R'. We don't need to worry about GNU ld support because older GNU ld just ignores the unknown SHF_GNU_RETAIN.
With this change, `__attribute__((retain))` functions/variables emitted by clang will get the SHF_GNU_RETAIN flag.
Differential Revision: https://reviews.llvm.org/D97448
show more ...
|
Revision tags: llvmorg-12.0.0-rc2 |
|
#
7f6e3316 |
| 23-Feb-2021 |
Jon Roelofs <jonathan_roelofs@apple.com> |
Support `#pragma clang section` directives on MachO targets
rdar://59560986
Differential Revision: https://reviews.llvm.org/D97233
|
#
11a53f47 |
| 24-Feb-2021 |
Petr Hosek <phosek@google.com> |
Revert "[InstrProfiling] Use nobits as __llvm_prf_cnts section type in ELF"
This reverts commit 6b286d93f7ec8518c685a302269e44b06a0a24f3 because in some cases when the optimizer evaluates the global
Revert "[InstrProfiling] Use nobits as __llvm_prf_cnts section type in ELF"
This reverts commit 6b286d93f7ec8518c685a302269e44b06a0a24f3 because in some cases when the optimizer evaluates the global initializer, __llvm_prf_cnts may not be entirely zero initialized.
show more ...
|
#
6b286d93 |
| 20-Feb-2021 |
Petr Hosek <phosek@google.com> |
[InstrProfiling] Use nobits as __llvm_prf_cnts section type in ELF
This can reduce the binary size because counters will no longer occupy space in the binary, instead they will be allocated by dynam
[InstrProfiling] Use nobits as __llvm_prf_cnts section type in ELF
This can reduce the binary size because counters will no longer occupy space in the binary, instead they will be allocated by dynamic linker.
Differential Revision: https://reviews.llvm.org/D97110
show more ...
|
#
12edddaf |
| 20-Feb-2021 |
Pan, Tao <tao.pan@intel.com> |
[CodeGen] Fix two dots between text section name and symbol name
There is a trailing dot in text section name if it has prefix, don't add repeated dot when connect text section name and symbol name.
[CodeGen] Fix two dots between text section name and symbol name
There is a trailing dot in text section name if it has prefix, don't add repeated dot when connect text section name and symbol name.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D96327
show more ...
|
#
796feb61 |
| 18-Feb-2021 |
Yang Fan <nullptr.cpp@gmail.com> |
[MC][ELF] Fix unused variable warning (NFC)
GCC warning: ``` /llvm-project/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp: In member function ‘virtual llvm::MCSection* llvm::TargetLoweringObjectF
[MC][ELF] Fix unused variable warning (NFC)
GCC warning: ``` /llvm-project/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp: In member function ‘virtual llvm::MCSection* llvm::TargetLoweringObjectFileELF::getSectionForLSDA(const llvm::Function&, const llvm::MCSymbol&, const llvm::TargetMachine&) const’: /llvm-project/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp:871:8: warning: variable ‘IsComdat’ set but not used [-Wunused-but-set-variable] 871 | bool IsComdat = false; | ^~~~~~~~ ```
show more ...
|
#
5517923b |
| 18-Feb-2021 |
Chen Zheng <czhengsz@cn.ibm.com> |
[XCOFF][NFC] make csect properties optional for getXCOFFSection
We are going to support debug sections for XCOFF. So the csect properties are not necessary. This patch makes these properties optiona
[XCOFF][NFC] make csect properties optional for getXCOFFSection
We are going to support debug sections for XCOFF. So the csect properties are not necessary. This patch makes these properties optional.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D95931
show more ...
|
#
d1a838ba |
| 16-Feb-2021 |
Sriraman Tallam <tmsriram@google.com> |
Basic block sections should enable function sections implicitly.
Basic block sections enables function sections implicitly, this is not needed and is inefficient with "=list" option.
We had basic b
Basic block sections should enable function sections implicitly.
Basic block sections enables function sections implicitly, this is not needed and is inefficient with "=list" option.
We had basic block sections enable function sections implicitly in clang. This is particularly inefficient with "=list" option as it places functions that do not have any basic block sections in separate sections. This causes unnecessary object file overhead for large applications.
This patch disables this implicit behavior. It only creates function sections for those functions that require basic block sections.
Further, there was an inconistent behavior with llc as llc was not turning on function sections by default. This patch makes llc and clang consistent and tests are added to check the new behavior.
This is the first of two patches and this adds functionality in LLVM to create a new section for the entry block if function sections is not enabled.
Differential Revision: https://reviews.llvm.org/D93876
show more ...
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3 |
|
#
16af9739 |
| 01-Feb-2021 |
Petr Hosek <phosek@google.com> |
[MC][ELF] Support for zero flag section groups
This change introduces support for zero flag ELF section groups to LLVM. LLVM already supports COMDAT sections, which in ELF are a special type of ELF
[MC][ELF] Support for zero flag section groups
This change introduces support for zero flag ELF section groups to LLVM. LLVM already supports COMDAT sections, which in ELF are a special type of ELF section groups. These are generally useful to enable linker GC where you want a group of sections to always travel together, that is to be either retained or discarded as a whole, but without the COMDAT semantics. Other ELF assemblers already support zero flag ELF section groups and this change helps us reach feature parity.
Differential Revision: https://reviews.llvm.org/D95851
show more ...
|
#
e44a1009 |
| 06-Feb-2021 |
Fangrui Song <i@maskray.me> |
.gcc_except_table: Set SHF_LINK_ORDER if binutils>=2.36, and drop unneeded unique ID for -fno-unique-section-names
GNU ld>=2.36 supports mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER sections in an ou
.gcc_except_table: Set SHF_LINK_ORDER if binutils>=2.36, and drop unneeded unique ID for -fno-unique-section-names
GNU ld>=2.36 supports mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER sections in an output section, so we can set SHF_LINK_ORDER if -fbinutils-version=2.36 or above.
If -fno-function-sections or older binutils, drop unique ID for -fno-unique-section-names. The users can just specify -fbinutils-version=2.36 or above to allow GC with both GNU ld and LLD. (LLD does not support garbage collection of non-group non-SHF_LINK_ORDER .gcc_except_table sections.)
show more ...
|
Revision tags: llvmorg-12.0.0-rc1, llvmorg-13-init |
|
#
34b60d8a |
| 26-Jan-2021 |
Fangrui Song <maskray@google.com> |
Add -fbinutils-version= to gate ELF features on the specified binutils version
There are two use cases.
Assembler We have accrued some code gated on MCAsmInfo::useIntegratedAssembler(). Some featu
Add -fbinutils-version= to gate ELF features on the specified binutils version
There are two use cases.
Assembler We have accrued some code gated on MCAsmInfo::useIntegratedAssembler(). Some features are supported by latest GNU as, but we have to use MCAsmInfo::useIntegratedAs() because the newer versions have not been widely adopted (e.g. SHF_LINK_ORDER 'o' and 'unique' linkage in 2.35, --compress-debug-sections= in 2.26).
Linker We want to use features supported only by LLD or very new GNU ld, or don't want to work around older GNU ld. We currently can't represent that "we don't care about old GNU ld". You can find such workarounds in a few other places, e.g. Mips/MipsAsmprinter.cpp PowerPC/PPCTOCRegDeps.cpp X86/X86MCInstrLower.cpp AArch64 TLS workaround for R_AARCH64_TLSLD_MOVW_DTPREL_* (PR ld/18276), R_AARCH64_TLSLE_LDST8_TPREL_LO12 (https://bugs.llvm.org/show_bug.cgi?id=36727 https://sourceware.org/bugzilla/show_bug.cgi?id=22969)
Mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER components (supported by LLD in D84001; GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi?id=16833 may take a while before available). This feature allows to garbage collect some unused sections (e.g. fragmented .gcc_except_table).
This patch adds `-fbinutils-version=` to clang and `-binutils-version` to llc. It changes one codegen place in SHF_MERGE to demonstrate its usage. `-fbinutils-version=2.35` means the produced object file does not care about GNU ld<2.35 compatibility. When `-fno-integrated-as` is specified, the produced assembly can be consumed by GNU as>=2.35, but older versions may not work.
`-fbinutils-version=none` means that we can use all ELF features, regardless of GNU as/ld support.
Both clang and llc need `parseBinutilsVersion`. Such command line parsing is usually implemented in `llvm/lib/CodeGen/CommandFlags.cpp` (LLVMCodeGen), however, ClangCodeGen does not depend on LLVMCodeGen. So I add `parseBinutilsVersion` to `llvm/lib/Target/TargetMachine.cpp` (LLVMTarget).
Differential Revision: https://reviews.llvm.org/D85474
show more ...
|
Revision tags: llvmorg-11.1.0-rc2 |
|
#
21bfd068 |
| 20-Jan-2021 |
Amanieu d'Antras <amanieu@gmail.com> |
[AArch64] Add support for the GNU ILP32 ABI
Add the aarch64[_be]-*-gnu_ilp32 targets to support the GNU ILP32 ABI for AArch64.
The needed codegen changes were mostly already implemented in D61259,
[AArch64] Add support for the GNU ILP32 ABI
Add the aarch64[_be]-*-gnu_ilp32 targets to support the GNU ILP32 ABI for AArch64.
The needed codegen changes were mostly already implemented in D61259, which added support for the watchOS ILP32 ABI. The main changes are: - Wiring up the new target to enable ILP32 codegen and MC. - ILP32 va_list support. - ILP32 TLSDESC relocation support.
There was existing MC support for ELF ILP32 relocations from D25159 which could be enabled by passing "-target-abi ilp32" to llvm-mc. This was changed to check for "gnu_ilp32" in the target triple instead. This shouldn't cause any issues since the existing support was slightly broken: it was generating ELF64 objects instead of the ELF32 object files expected by the GNU ILP32 toolchain.
This target has been tested by running the full rustc testsuite on a big-endian ILP32 system based on the GCC ILP32 toolchain.
Reviewed By: kristof.beyls
Differential Revision: https://reviews.llvm.org/D94143
show more ...
|
#
12fc9ca3 |
| 13-Jan-2021 |
Kazu Hirata <kazu@google.com> |
[llvm] Remove redundant string initialization (NFC)
Identified with readability-redundant-string-init.
|
Revision tags: llvmorg-11.1.0-rc1 |
|
#
8f004471 |
| 02-Jan-2021 |
Brandon Bergren <bdragon@FreeBSD.org> |
[PowerPC] Add the LLVM triple for powerpcle [1/5]
Add a triple for powerpcle-*-*.
This is a little-endian encoding of the 32-bit PowerPC ABI, useful in certain niche situations:
1) A loader such a
[PowerPC] Add the LLVM triple for powerpcle [1/5]
Add a triple for powerpcle-*-*.
This is a little-endian encoding of the 32-bit PowerPC ABI, useful in certain niche situations:
1) A loader such as the FreeBSD loader which will be loading a little endian kernel. This is required for PowerPC64LE to load properly in pseries VMs. Such a loader is implemented as a freestanding ELF32 LSB binary.
2) Userspace emulation of a 32-bit LE architecture such as x86 on 64-bit hosts such as PowerPC64LE with tools like box86 requires having a 32-bit LE toolchain and library set, as they operate by translating only the main binary and switching to native code when making library calls.
3) The Void Linux for PowerPC project is experimenting with running an entire powerpcle userland.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D93918
show more ...
|