History log of /llvm-project/llvm/lib/Transforms/Utils/ModuleUtils.cpp (Results 26 – 50 of 96)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# 611ffcf4 14-Jul-2022 Kazu Hirata <kazu@google.com>

[llvm] Use value instead of getValue (NFC)


# 41fba3c1 05-Jul-2022 Joseph Huber <jhuber6@vols.utk.edu>

[Metadata] Add 'exclude' metadata to add the exclude flags on globals

This patchs adds a new metadata kind `exclude` which implies that the
global variable should be given the necessary flags during

[Metadata] Add 'exclude' metadata to add the exclude flags on globals

This patchs adds a new metadata kind `exclude` which implies that the
global variable should be given the necessary flags during code
generation to not be included in the final executable. This is done
using the ``SHF_EXCLUDE`` flag on ELF for example. This should make it
easier to specify this flag on a variable without needing to explicitly
check the section name in the target backend.

Depends on D129053 D129052

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D129151

show more ...


# ed801ad5 02-Jul-2022 Joseph Huber <jhuber6@vols.utk.edu>

[Clang] Use metadata to make identifying embedded objects easier

Currently we use the `embedBufferInModule` function to store binary
strings containing device offloading data inside the host object

[Clang] Use metadata to make identifying embedded objects easier

Currently we use the `embedBufferInModule` function to store binary
strings containing device offloading data inside the host object to
create a fatbinary. In the case of LTO, we need to extract this object
from the LLVM-IR. This patch adds a metadata node for the embedded
objects containing the embedded pointers and the sections they were
stored at. This should create a cleaner interface for identifying these
values.

In the future it may be worthwhile to also encode an `ID` in the
metadata corresponding to the object's special section type if relevant.
This would allow us to extract the data from an object file and LLVM-IR
using the same ID.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D129033

show more ...


# a7938c74 26-Jun-2022 Kazu Hirata <kazu@google.com>

[llvm] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.


# 3b7c3a65 25-Jun-2022 Kazu Hirata <kazu@google.com>

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.


# aa8feeef 25-Jun-2022 Kazu Hirata <kazu@google.com>

Don't use Optional::hasValue (NFC)


Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# 984a0dc3 25-Mar-2022 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Use new offloading binary when embedding offloading images

The previous patch introduced the offloading binary format so we can
store some metada along with the binary image. This patch int

[OpenMP] Use new offloading binary when embedding offloading images

The previous patch introduced the offloading binary format so we can
store some metada along with the binary image. This patch introduces
using this inside the linker wrapper and Clang instead of the previous
method that embedded the metadata in the section name.

Differential Revision: https://reviews.llvm.org/D122683

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# a494ae43 01-Mar-2022 serge-sans-paille <sguelton@redhat.com>

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120741

show more ...


# 7aef8b37 24-Feb-2022 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Make section variable external to prevent collisions

Summary:
We use a section to embed offloading code into the host for later
linking. This is normally unique to the translation unit as i

[OpenMP] Make section variable external to prevent collisions

Summary:
We use a section to embed offloading code into the host for later
linking. This is normally unique to the translation unit as it is thrown
away during linking. However, if the user performs a relocatable link
the sections will be merged and we won't be able to access the files
stored inside. This patch changes the section variables to have external
linkage and a name defined by the section name, so if two sections are
combined during linking we get an error.

show more ...


Revision tags: llvmorg-14.0.0-rc1
# 6b4ebdd4 03-Feb-2022 Simon Pilgrim <llvm-dev@redking.me.uk>

ModuleUtils - VFABI::setVectorVariantNames - use ArrayRef<> instead of const SmallVector to pass argument


Revision tags: llvmorg-15-init
# 85dfe19b 01-Feb-2022 Fangrui Song <i@maskray.me>

[ModuleUtils] Move EmbedBufferInModule to LLVMTransformsUtils

D116542 adds EmbedBufferInModule which introduces a layer violation
(https://llvm.org/docs/CodingStandards.html#library-layering).
See 2

[ModuleUtils] Move EmbedBufferInModule to LLVMTransformsUtils

D116542 adds EmbedBufferInModule which introduces a layer violation
(https://llvm.org/docs/CodingStandards.html#library-layering).
See 2d5f857a1eaf5f7a806d12953c79b96ed8952da8 for detail.

EmbedBufferInModule does not use BitcodeWriter functionality and should be moved
LLVMTransformsUtils. While here, change the function case to the prevailing
convention.

It seems that EmbedBufferInModule just follows the steps of
EmbedBitcodeInModule. EmbedBitcodeInModule calls WriteBitcodeToFile but has IR
update operations which ideally should be refactored to another library.

Reviewed By: jhuber6

Differential Revision: https://reviews.llvm.org/D118666

show more ...


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2
# c8189da2 07-Jan-2022 Nikita Popov <npopov@redhat.com>

[ModuleUtils] Remove dead arg from filterDeadComdatFunctions() (NFC)

The module argument is no longer used.


# 32808cfb 16-Dec-2021 Nikita Popov <npopov@redhat.com>

[IR] Track users of comdats

Track all GlobalObjects that reference a given comdat, which allows
determining whether a function in a comdat is dead without scanning
the whole module.

In particular,

[IR] Track users of comdats

Track all GlobalObjects that reference a given comdat, which allows
determining whether a function in a comdat is dead without scanning
the whole module.

In particular, this makes filterDeadComdatFunctions() have complexity
O(#DeadFunctions) rather than O(#SymbolsInModule), which addresses
half of the compile-time issue exposed by D115545.

Differential Revision: https://reviews.llvm.org/D115864

show more ...


Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3
# 92c9ff6d 09-Sep-2021 Kazu Hirata <kazu@google.com>

[IR, Transforms] Use arg_empty (NFC)


Revision tags: llvmorg-13.0.0-rc2
# 3f4d00bc 18-Aug-2021 Arthur Eubanks <aeubanks@google.com>

[NFC] More get/removeAttribute() cleanup


# 46cf8253 16-Aug-2021 Arthur Eubanks <aeubanks@google.com>

[NFC] Replace Function handling of attributes with less confusing calls

To avoid magic constants and confusing indexes.


Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init
# f6413d8a 22-Jul-2021 Kazu Hirata <kazu@google.com>

[Transforms] Remove getOrCreateInitFunction (NFC)

The last use was removed on Jan 16, 2019 in commit
81101de5853b4ed64640220a086a67b16f36f153.


# 7b789562 21-Jul-2021 Fangrui Song <i@maskray.me>

[sanitizer] Place module_ctor/module_dtor in llvm.used

This removes an abuse of ELF linker behaviors while keeping Mach-O/COFF linker
behaviors unchanged.

ELF: when module_ctor is in a comdat, this

[sanitizer] Place module_ctor/module_dtor in llvm.used

This removes an abuse of ELF linker behaviors while keeping Mach-O/COFF linker
behaviors unchanged.

ELF: when module_ctor is in a comdat, this patch removes reliance on a linker
abuse (an SHT_INIT_ARRAY in a section group retains the whole group) by using
SHF_GNU_RETAIN. No linker behavior difference when module_ctor is not in a comdat.

Mach-O: module_ctor gets `N_NO_DEAD_STRIP`. No linker behavior difference
because module_ctor is already referenced by a `S_MOD_INIT_FUNC_POINTERS`
section (GC root).

PE/COFF: no-op. SanitizerCoverage already appends module_ctor to `llvm.used`.
Other sanitizers: llvm.used for local linkage is not implemented in
`TargetLoweringObjectFileCOFF::emitLinkerDirectives` (once implemented or
switched to a non-local linkage, COFF can use module_ctor in comdat (i.e.
generalize ELF-specific rL301586)).

There is no object file size difference.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D106246

show more ...


Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1
# 60c60dd1 29-Apr-2021 Reshabh Sharma <Reshabhkumar.Sharma@amd.com>

[ASAN] NFC: Use addrspace cast for pointers in non-zero addrspace

Pointers in non-zero address spaces need to be address space
casted before appending to the used list.

Reviewed by: vitalybuka

Dif

[ASAN] NFC: Use addrspace cast for pointers in non-zero addrspace

Pointers in non-zero address spaces need to be address space
casted before appending to the used list.

Reviewed by: vitalybuka

Differential Revision: https://reviews.llvm.org/D101363

show more ...


# 775a9483 21-Apr-2021 Fangrui Song <i@maskray.me>

[IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables

On ELF targets, if a function has uwtable or personality, or does not have
nounwind (`needs

[IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables

On ELF targets, if a function has uwtable or personality, or does not have
nounwind (`needsUnwindTableEntry`), it marks that `.eh_frame` is needed in the module.

Then, a function gets `.eh_frame` if `needsUnwindTableEntry` or `-g[123]` is specified.
(i.e. If -g[123], every function gets `.eh_frame`.
This behavior is strange but that is the status quo on GCC and Clang.)

Let's take asan as an example. Other sanitizers are similar.
`asan.module_[cd]tor` has no attribute. `needsUnwindTableEntry` returns true,
so every function gets `.eh_frame` if `-g[123]` is specified.
This is the root cause that
`-fno-exceptions -fno-asynchronous-unwind-tables -g` produces .debug_frame
while
`-fno-exceptions -fno-asynchronous-unwind-tables -g -fsanitize=address` produces .eh_frame.

This patch

* sets the nounwind attribute on sanitizer module ctor/dtor.
* let Clang emit a module flag metadata "uwtable" for -fasynchronous-unwind-tables. If "uwtable" is set, sanitizer module ctor/dtor additionally get the uwtable attribute.

The "uwtable" mechanism is generic: synthesized functions not cloned/specialized
from existing ones should consider `Function::createWithDefaultAttr` instead of
`Function::create` if they want to get some default attributes which
have more of module semantics.

Other candidates: "frame-pointer" (https://github.com/ClangBuiltLinux/linux/issues/955
https://github.com/ClangBuiltLinux/linux/issues/1238), dso_local, etc.

Differential Revision: https://reviews.llvm.org/D100251

show more ...


Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3
# c6e5c465 25-Feb-2021 Hans Wennborg <hans@chromium.org>

Don't use $ as suffix for symbol names in ThinLTOBitcodeWriter and other places

Using $ breaks demangling of the symbols. For example,

$ c++filt _Z3foov\$123
_Z3foov$123

This causes problems for d

Don't use $ as suffix for symbol names in ThinLTOBitcodeWriter and other places

Using $ breaks demangling of the symbols. For example,

$ c++filt _Z3foov\$123
_Z3foov$123

This causes problems for developers who would like to see nice stack traces
etc., but also for automatic crash tracking systems which try to organize
crashes based on the stack traces.

Instead, use the period as suffix separator, since Itanium demanglers normally
ignore such suffixes:

$ c++filt _Z3foov.123
foo() [clone .123]

This is already done in some places; try to do it everywhere.

Differential revision: https://reviews.llvm.org/D97484

show more ...


Revision tags: llvmorg-12.0.0-rc2
# fde55a9c 19-Feb-2021 Teresa Johnson <tejohnson@google.com>

[LTO] Fix cloning of llvm*.used when splitting module

Refines the fix in 3c4c205060c9398da705eb71b63ddd8a04999de9 to only
put globals whose defs were cloned into the split regular LTO module
on the

[LTO] Fix cloning of llvm*.used when splitting module

Refines the fix in 3c4c205060c9398da705eb71b63ddd8a04999de9 to only
put globals whose defs were cloned into the split regular LTO module
on the cloned llvm*.used globals. This avoids an issue where one of the
attached values was a local that was promoted in the original module
after the module was cloned. We only need to have the values defined in
the new module on those globals.

Fixes PR49251.

Differential Revision: https://reviews.llvm.org/D97013

show more ...


Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2
# d3f89314 10-Jun-2020 Marco Elver <elver@google.com>

[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2]

[ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to
modpost failing; v2 fixes this. More info:
htt

[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2]

[ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to
modpost failing; v2 fixes this. More info:
https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ]

This makes -fsanitize=kernel-address emit the correct globals
constructors for the kernel. We had to do the following:

* Disable generation of constructors that rely on linker features such
as dead-global elimination.

* Only instrument globals *not* in explicit sections. The kernel uses
sections for special globals, which we should not touch.

* Do not instrument globals that are prefixed with "__" nor that are
aliased by a symbol that is prefixed with "__". For example, modpost
relies on specially named aliases to find globals and checks their
contents. Unfortunately modpost relies on size stored as ELF debug info
and any padding of globals currently causes the debug info to cause size
reported to be *with* redzone which throws modpost off.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493

Tested:
* With 'clang/test/CodeGen/asan-globals.cpp'.

* With test_kasan.ko, we can see:

BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan]

* allyesconfig, allmodconfig (x86_64)

Reviewed By: glider

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D81390

show more ...


# c6ec352a 08-Jun-2020 Marco Elver <elver@google.com>

Revert "[KernelAddressSanitizer] Make globals constructors compatible with kernel"

This reverts commit 866ee2353f7d0224644799d0d1faed53c7f3a06d.

Building the kernel results in modpost failures due

Revert "[KernelAddressSanitizer] Make globals constructors compatible with kernel"

This reverts commit 866ee2353f7d0224644799d0d1faed53c7f3a06d.

Building the kernel results in modpost failures due to modpost relying
on debug info and inspecting kernel modules' globals:
https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783

show more ...


# 866ee235 29-May-2020 Marco Elver <elver@google.com>

[KernelAddressSanitizer] Make globals constructors compatible with kernel

Summary:
This makes -fsanitize=kernel-address emit the correct globals
constructors for the kernel. We had to do the followi

[KernelAddressSanitizer] Make globals constructors compatible with kernel

Summary:
This makes -fsanitize=kernel-address emit the correct globals
constructors for the kernel. We had to do the following:

- Disable generation of constructors that rely on linker features such
as dead-global elimination.

- Only emit constructors for globals *not* in explicit sections. The
kernel uses sections for special globals, which we should not touch.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493

Tested:
1. With 'clang/test/CodeGen/asan-globals.cpp'.
2. With test_kasan.ko, we can see:

BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan]

Reviewers: glider, andreyknvl

Reviewed By: glider

Subscribers: cfe-commits, nickdesaulniers, hiraditya, llvm-commits

Tags: #llvm, #clang

Differential Revision: https://reviews.llvm.org/D80805

show more ...


1234