History log of /llvm-project/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp (Results 101 – 125 of 536)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


12345678910>>...22