#
18f8106f |
| 29-Jan-2025 |
Joel E. Denny <jdenny.ornl@gmail.com> |
[KernelInfo] Implement new LLVM IR pass for GPU code analysis (#102944)
This patch implements an LLVM IR pass, named kernel-info, that reports
various statistics for codes compiled for GPUs. The ul
[KernelInfo] Implement new LLVM IR pass for GPU code analysis (#102944)
This patch implements an LLVM IR pass, named kernel-info, that reports
various statistics for codes compiled for GPUs. The ultimate goal of
these statistics to help identify bad code patterns and ways to mitigate
them. The pass operates at the LLVM IR level so that it can, in theory,
support any LLVM-based compiler for programming languages supporting
GPUs. It has been tested so far with LLVM IR generated by Clang for
OpenMP offload codes targeting NVIDIA GPUs and AMD GPUs.
By default, the pass runs at the end of LTO, and options like
``-Rpass=kernel-info`` enable its remarks. Example `opt` and `clang`
command lines appear in `llvm/docs/KernelInfo.rst`. Remarks include
summary statistics (e.g., total size of static allocas) and individual
occurrences (e.g., source location of each alloca). Examples of its
output appear in tests in `llvm/test/Analysis/KernelInfo`.
show more ...
|
Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
f03b100e |
| 02-Jan-2025 |
王宇逸 <Strawberry_Str@hotmail.com> |
[Cygwin] Fix global variable dll import (#121439)
This PR is necessary for cygwin target of Rust.
References:
*
https://github.com/rust-lang/llvm-project/commit/86657cc39f8e42ae73be810fb0703dda
[Cygwin] Fix global variable dll import (#121439)
This PR is necessary for cygwin target of Rust.
References:
*
https://github.com/rust-lang/llvm-project/commit/86657cc39f8e42ae73be810fb0703ddac0eeef94
*
https://github.com/Berrysoft/llvm-project/commit/a807e9f077351d3c6a68f4abe74c94a039759a2e
show more ...
|
Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3 |
|
#
7fe486ac |
| 12-Aug-2024 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
TargetMachine: Move trivial setter/getter to header
The others are already inline here.
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
4169338e |
| 28-Jun-2024 |
Nikita Popov <npopov@redhat.com> |
[IR] Don't include Module.h in Analysis.h (NFC) (#97023)
Replace it with a forward declaration instead. Analysis.h is pulled in
by all passes, but not all passes need to access the module.
|
#
9df71d76 |
| 28-Jun-2024 |
Nikita Popov <npopov@redhat.com> |
[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)
Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, re
[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)
Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.
show more ...
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4 |
|
#
281d7160 |
| 16-Apr-2024 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Change how we treat functions with explicit sections as small/large (#88172)
Following #78348, we should treat functions with an explicit section as
small, unless the section name is (or has
[X86] Change how we treat functions with explicit sections as small/large (#88172)
Following #78348, we should treat functions with an explicit section as
small, unless the section name is (or has the prefix) ".ltext".
Clang emits global initializers into a ".text.startup" section on Linux.
If we mix small/medium code model object files with large code model
object files, we'll end up mixing sections with and without the large
section flag.
Reland of #87838 with a check for non-ELF platforms in
TargetMachine::isLargeGlobalValue(), otherwise MCJIT on Windows tests
fail.
show more ...
|
#
922700df |
| 08-Apr-2024 |
Arthur Eubanks <aeubanks@google.com> |
Revert "[X86] Change how we treat functions with explicit sections as small/large (#87838)"
This reverts commit e27c3736f975ca463476223c465e4777186f603f.
Breaks ExecutionEngine/MCJIT/test-global-ct
Revert "[X86] Change how we treat functions with explicit sections as small/large (#87838)"
This reverts commit e27c3736f975ca463476223c465e4777186f603f.
Breaks ExecutionEngine/MCJIT/test-global-ctors.ll on windows, e.g. https://lab.llvm.org/buildbot/#/builders/117/builds/18749.
show more ...
|
#
e27c3736 |
| 08-Apr-2024 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Change how we treat functions with explicit sections as small/large (#87838)
Following #78348, we should treat functions with an explicit section as
small, unless the section name is (or has
[X86] Change how we treat functions with explicit sections as small/large (#87838)
Following #78348, we should treat functions with an explicit section as
small, unless the section name is (or has the prefix) ".ltext".
Clang emits global initializers into a ".text.startup" section on Linux.
If we mix small/medium code model object files with large code model
object files, we'll end up mixing sections with and without the large
section flag.
show more ...
|
Revision tags: llvmorg-18.1.3, llvmorg-18.1.2 |
|
#
6bbb73b4 |
| 12-Mar-2024 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Fix determining if globals with size <8 bits are large (#84975)
Previously any global under 8 bits would accidentally be considered 0
sized, which is considered a large global.
|
#
94c988bc |
| 11-Mar-2024 |
Arthur Eubanks <aeubanks@google.com> |
[NFC] Remove unused parameter from shouldAssumeDSOLocal()
|
Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2 |
|
#
198652a0 |
| 30-Jan-2024 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Treat __start_*/__stop_* symbols as large (#79909)
Followup to #79884.
The linker adds __start_foo/__stop_foo symbols pointing to the
beginning/end of the foo section. These can be far awa
[X86] Treat __start_*/__stop_* symbols as large (#79909)
Followup to #79884.
The linker adds __start_foo/__stop_foo symbols pointing to the
beginning/end of the foo section. These can be far away from text, so
treat them as large symbols under the medium/large code models.
Performance to access these is almost certainly not important.
show more ...
|
Revision tags: llvmorg-18.1.0-rc1 |
|
#
d6e07e08 |
| 29-Jan-2024 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Treat __ehdr_start as large (#79884)
The __ehdr_start symbol is added by the linker and points to the ELF
file headers, which can be very far away from text. Treat it as a large
symbol under
[X86] Treat __ehdr_start as large (#79884)
The __ehdr_start symbol is added by the linker and points to the ELF
file headers, which can be very far away from text. Treat it as a large
symbol under the medium/large code models. Performance to access
__ehdr_start is almost certainly not important.
There are a couple of other symbols that the linker adds [1], but this
is the most relevant one that may be far away from text.
[1]
https://github.com/llvm/llvm-project/blob/547c395b279a93357082ac06cf3e8fe37ebfc3fe/lld/ELF/Writer.cpp#L226
show more ...
|
Revision tags: llvmorg-19-init |
|
#
03a61d34 |
| 24-Jan-2024 |
Paul Kirth <paulkirth@google.com> |
[RISCV] Support TLSDESC in the RISC-V backend (#66915)
This patch adds basic TLSDESC support in the RISC-V backend.
Specifically, we add new relocation types for TLSDESC, as prescribed in
https
[RISCV] Support TLSDESC in the RISC-V backend (#66915)
This patch adds basic TLSDESC support in the RISC-V backend.
Specifically, we add new relocation types for TLSDESC, as prescribed in
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, and add a
new pseudo instruction to simplify code generation.
This patch does not try to optimize the local dynamic case, which can be
improved in separate patches.
Linker side changes will also be handled separately.
The current implementation is only enabled when passing the new
`-enable-tlsdesc` codegen flag.
show more ...
|
#
00647a18 |
| 17-Jan-2024 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Don't respect large data threshold for globals with an explicit section (#78348)
If multiple globals are placed in an explicit section, there's a chance
that the large data threshold will cau
[X86] Don't respect large data threshold for globals with an explicit section (#78348)
If multiple globals are placed in an explicit section, there's a chance
that the large data threshold will cause the different globals to be
inconsistent in whether they're large or small. Mixing sections with
mismatched large section flags can cause undesirable issues like
increased relocation pressure because there may be 32-bit references to
the section in some TUs, but the section is considered large since input
section flags are unioned and other TUs added the large section flag.
An explicit code model on the global still overrides the decision. We
can do this for globals without any references to them, like what we did
with asan_globals in #74514. If we have some precompiled small code
model files where asan_globals is not considered large mixed with
medium/large code model files, that's ok because the section is
considered large and placed farther. However, overriding the code model
for globals in some TUs but not others and having references to them
from code will still result in the above undesired behavior.
This mitigates a whole class of mismatched large section flag issues
like what #77986 was trying to fix.
This ends up not adding the SHF_X86_64_LARGE section flag on explicit
sections in the medium/large code model. This is ok for the large code
model since all references from large text must use 64-bit relocations
anyway.
show more ...
|
#
7433b1ca |
| 21-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
Reapply "[X86] Set SHF_X86_64_LARGE for globals with explicit well-known large section name (#74381)"
This reverts commit 19fff858931bf575b63a0078cc553f8f93cced20.
Now that explicit large globals a
Reapply "[X86] Set SHF_X86_64_LARGE for globals with explicit well-known large section name (#74381)"
This reverts commit 19fff858931bf575b63a0078cc553f8f93cced20.
Now that explicit large globals are handled properly in the small code model.
show more ...
|
#
239a41e8 |
| 14-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
Re-Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)
For non-GlobalValue references, the small and medium code models can use 32 bit constants.
Re-Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)
For non-GlobalValue references, the small and medium code models can use 32 bit constants.
For GlobalValue references, use TargetMachine::isLargeGlobalObject(). Look through aliases for determining if a GlobalValue is small or large. Even the large code model can reference small objects with 32 bit constants as long as we're in no-pic mode, or if the reference is offset from the GOT.
Original commit broke the build...
First reland broke large PIC builds referencing small data since it was using GOTOFF as a 32-bit constant.
show more ...
|
#
15617d14 |
| 14-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
Revert "Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)"
This reverts commit ec92d74a0ef89b9dd46aee6ec8aca6bfd3c66a54.
Breaks some compiler-
Revert "Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)"
This reverts commit ec92d74a0ef89b9dd46aee6ec8aca6bfd3c66a54.
Breaks some compiler-rt tests, e.g. https://lab.llvm.org/buildbot/#/builders/37/builds/28834
show more ...
|
#
ec92d74a |
| 14-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)
For non-GlobalValue references, the small and medium code models can use 32 bit constants.
F
Reland [X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)
For non-GlobalValue references, the small and medium code models can use 32 bit constants.
For GlobalValue references, use TargetMachine::isLargeGlobalObject(). Look through aliases for determining if a GlobalValue is small or large. Even the large code model can reference small objects with 32 bit constants as long as we're in no-pic mode, or if the reference is offset from the GOT.
Original commit broke the build...
show more ...
|
#
f0c03da6 |
| 14-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
Revert "[X86] Respect code models more when determining if a global reference can fit in 32 bits" (#75500)
Reverts llvm/llvm-project#75386
Breaks build.
|
#
5e38ba26 |
| 14-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)
For non-GlobalValue references, the small and medium code models can use
32 bit constants.
For G
[X86] Respect code models more when determining if a global reference can fit in 32 bits (#75386)
For non-GlobalValue references, the small and medium code models can use
32 bit constants.
For GlobalValue references, use TargetMachine::isLargeGlobalObject().
Look through aliases for determining if a GlobalValue is small or large.
Even the large code model can reference small objects with 32 bit
constants as long as we're in no-pic mode, or if the reference is offset
from the GOT.
show more ...
|
#
19fff858 |
| 13-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
Revert "[X86] Set SHF_X86_64_LARGE for globals with explicit well-known large section name (#74381)"
This reverts commit 323451ab88866c42c87971cbc670771bd0d48692.
Code with these section names in t
Revert "[X86] Set SHF_X86_64_LARGE for globals with explicit well-known large section name (#74381)"
This reverts commit 323451ab88866c42c87971cbc670771bd0d48692.
Code with these section names in the wild doesn't compile because support for large globals in the small code model is not complete yet.
show more ...
|
#
f82c85d2 |
| 12-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Handle unsized types in TargetMachine::isLargeGlobalObject() (#74952)
isLargeGlobalObject() didn't handle opaque types, resulting in crashes.
|
#
38501311 |
| 12-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Handle ifuncs in TargetMachine::isLargeGlobalObject() (#74911)
isLargeGlobalObject() didn't handle GlobalIFuncs, resulting in crashes.
Treat ifuncs the same as normal Functions.
|
#
ddebce70 |
| 05-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Respect code_model when determining if a global is small/large (#74498)
Using the GlobalVariable code_model property added in #72077.
code_model = "small" means the global should be treated
[X86] Respect code_model when determining if a global is small/large (#74498)
Using the GlobalVariable code_model property added in #72077.
code_model = "small" means the global should be treated as small
regardless of the TargetMachine code model.
code_model = "large" means the global should be treated as large
regardless of the TargetMachine code model.
Inferring small/large based on a known section name still takes
precedence for correctness.
The intention is to use this for globals that are accessed very
infrequently but also take up a lot of space in the binary to mitigate
relocation overflows. Prime examples are globals that go in
"__llvm_prf_names" for coverage/PGO instrumented builds and
"asan_globals" for ASan builds.
show more ...
|
#
323451ab |
| 05-Dec-2023 |
Arthur Eubanks <aeubanks@google.com> |
[X86] Set SHF_X86_64_LARGE for globals with explicit well-known large section name (#74381)
Globals marked with the .lbss/.ldata/.lrodata should automatically be
treated as large.
Do this regardle
[X86] Set SHF_X86_64_LARGE for globals with explicit well-known large section name (#74381)
Globals marked with the .lbss/.ldata/.lrodata should automatically be
treated as large.
Do this regardless of the code model for consistency when mixing object
files compiled with different code models.
Basically the other half of #70748.
Example in the wild:
https://codebrowser.dev/qt5/qtbase/src/testlib/qtestcase.cpp.html#1664
show more ...
|