aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
AgeCommit message (Collapse)AuthorFilesLines
2024-02-15[X86] Use ".lrodata" prefix for large mergeable constants (#81900)Arthur Eubanks1-6/+7
Otherwise with a small enough large-data-threshold, we can get .rodata.* sections marked large, making .rodata large in the final binary.
2024-01-31[llvm] Use StringRef::starts_with (NFC)Kazu Hirata1-1/+1
2024-01-31[AIX] [XCOFF] Add support for common and local common symbols in the TOC ↵Zaara Syeda1-1/+3
(#79530) This patch adds support for common and local symbols in the TOC for AIX. Note that we need to update isVirtualSection so as a common symbol in TOC will have the symbol type XTY_CM and will be initialized when placed in the TOC so sections with this type are no longer virtual. --------- Co-authored-by: Zaara Syeda <syzaara@ca.ibm.com>
2024-01-09[Coverage] Mark coverage sections as metadata sections on COFF. (#76834)Zequan Wu1-1/+10
Mark `.lcovmap$M`, `.lcovfun$M`, `.lcovd` and `.lcovn` as metadata sections on COFF so they are not loaded into memory.
2023-12-19[SystemZ][z/OS] Add exception handling for XPLINK (#74638)Yusra Syeda1-0/+7
Adds emitting the exception table and the EH registers for XPLINK. --------- Co-authored-by: Yusra Syeda <yusra.syeda@ibm.com>
2023-12-14Re-Reland [X86] Respect code models more when determining if a global ↵Arthur Eubanks1-2/+2
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.
2023-12-14Revert "Reland [X86] Respect code models more when determining if a global ↵Arthur Eubanks1-2/+2
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
2023-12-14[Profile] Add binary profile correlation for code coverage. (#69493)Zequan Wu1-0/+4
## Motivation Since we don't need the metadata sections at runtime, we can somehow offload them from memory at runtime. Initially, I explored [debug info correlation](https://discourse.llvm.org/t/instrprofiling-lightweight-instrumentation/59113), which is used for PGO with value profiling disabled. However, it currently only works with DWARF and it's be hard to add such artificial debug info for every function in to CodeView which is used on Windows. So, offloading profile metadata sections at runtime seems to be a platform independent option. ## Design The idea is to use new section names for profile name and data sections and mark them as metadata sections. Under this mode, the new sections are non-SHF_ALLOC in ELF. So, they are not loaded into memory at runtime and can be stripped away as a post-linking step. After the process exits, the generated raw profiles will contains only headers + counters. llvm-profdata can be used correlate raw profiles with the unstripped binary to generate indexed profile. ## Data For chromium base_unittests with code coverage on linux, the binary size overhead due to instrumentation reduced from 64M to 38.8M (39.4%) and the raw profile files size reduce from 128M to 68M (46.9%) ``` $ bloaty out/cov/base_unittests.stripped -- out/no-cov/base_unittests.stripped FILE SIZE VM SIZE -------------- -------------- +121% +30.4Mi +121% +30.4Mi .text [NEW] +14.6Mi [NEW] +14.6Mi __llvm_prf_data [NEW] +10.6Mi [NEW] +10.6Mi __llvm_prf_names [NEW] +5.86Mi [NEW] +5.86Mi __llvm_prf_cnts +95% +1.75Mi +95% +1.75Mi .eh_frame +108% +400Ki +108% +400Ki .eh_frame_hdr +9.5% +211Ki +9.5% +211Ki .rela.dyn +9.2% +95.0Ki +9.2% +95.0Ki .data.rel.ro +5.0% +87.3Ki +5.0% +87.3Ki .rodata [ = ] 0 +13% +47.0Ki .bss +40% +1.78Ki +40% +1.78Ki .got +12% +1.49Ki +12% +1.49Ki .gcc_except_table [ = ] 0 +65% +1.23Ki .relro_padding +62% +1.20Ki [ = ] 0 [Unmapped] +13% +448 +19% +448 .init_array +8.8% +192 [ = ] 0 [ELF Section Headers] +0.0% +136 +0.0% +80 [7 Others] +0.1% +96 +0.1% +96 .dynsym +1.2% +96 +1.2% +96 .rela.plt +1.5% +80 +1.2% +64 .plt [ = ] 0 -99.2% -3.68Ki [LOAD #5 [RW]] +195% +64.0Mi +194% +64.0Mi TOTAL $ bloaty out/cov-cor/base_unittests.stripped -- out/no-cov/base_unittests.stripped FILE SIZE VM SIZE -------------- -------------- +121% +30.4Mi +121% +30.4Mi .text [NEW] +5.86Mi [NEW] +5.86Mi __llvm_prf_cnts +95% +1.75Mi +95% +1.75Mi .eh_frame +108% +400Ki +108% +400Ki .eh_frame_hdr +9.5% +211Ki +9.5% +211Ki .rela.dyn +9.2% +95.0Ki +9.2% +95.0Ki .data.rel.ro +5.0% +87.3Ki +5.0% +87.3Ki .rodata [ = ] 0 +13% +47.0Ki .bss +40% +1.78Ki +40% +1.78Ki .got +12% +1.49Ki +12% +1.49Ki .gcc_except_table +13% +448 +19% +448 .init_array +0.1% +96 +0.1% +96 .dynsym +1.2% +96 +1.2% +96 .rela.plt +1.2% +64 +1.2% +64 .plt +2.9% +64 [ = ] 0 [ELF Section Headers] +0.0% +40 +0.0% +40 .data +1.2% +32 +1.2% +32 .got.plt +0.0% +24 +0.0% +8 [5 Others] [ = ] 0 -22.9% -872 [LOAD #5 [RW]] -74.5% -1.44Ki [ = ] 0 [Unmapped] [ = ] 0 -76.5% -1.45Ki .relro_padding +118% +38.8Mi +117% +38.8Mi TOTAL ``` A few things to note: 1. llvm-profdata doesn't support filter raw profiles by binary id yet, so when a raw profile doesn't belongs to the binary being digested by llvm-profdata, merging will fail. Once this is implemented, llvm-profdata should be able to only merge raw profiles with the same binary id as the binary and discard the rest (with mismatched/missing binary id). The workflow I have in mind is to have scripts invoke llvm-profdata to get all binary ids for all raw profiles, and selectively choose the raw pnrofiles with matching binary id and the binary to llvm-profdata for merging. 2. Note: In COFF, currently they are still loaded into memory but not used. I didn't do it in this patch because I noticed that `.lcovmap` and `.lcovfunc` are loaded into memory. A separate patch will address it. 3. This should works with PGO when value profiling is disabled as debug info correlation currently doing, though I haven't tested this yet.
2023-12-14Reland [X86] Respect code models more when determining if a global reference ↵Arthur Eubanks1-2/+2
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...
2023-12-14Revert "[X86] Respect code models more when determining if a global ↵Arthur Eubanks1-2/+2
reference can fit in 32 bits" (#75500) Reverts llvm/llvm-project#75386 Breaks build.
2023-12-14[X86] Respect code models more when determining if a global reference can ↵Arthur Eubanks1-2/+2
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.
2023-12-11[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)Kazu Hirata1-19/+14
This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-12-09[ADT] Rename SmallString::{starts,ends}with to {starts,ends}_with (#74916)Kazu Hirata1-1/+1
This patch renames {starts,ends}with to {starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. Since there are only a handful of occurrences, this patch skips the deprecation phase and simply renames them.
2023-12-08[PowerPC] Move __ehinfo TOC entries to the end of the TOC section (#73586)Maryam Moghadas1-5/+11
On AIX, the __ehinfo toc-entry is never referenced directly using instructions, therefore we can allocate them with the TE storage mapping class to move them to the end of TOC.
2023-12-01Reland [X86] With large code model, put functions into .ltext with large ↵Arthur Eubanks1-11/+4
section flag (#73037) So that when mixing small and large text, large text stays out of the way of the rest of the binary. This is useful for mixing precompiled small code model object files and built-from-source large code model binaries so that the the text sections don't get merged. The reland fixes an issue where a function in the large code model would reference small data without GOTOFF. This was incorrectly reverted in 76f78ecc789d58baa3a88b2fe2a57428f07e5362.
2023-12-01Revert "Reland [X86] With large code model, put functions into .ltext with ↵Dmitri Gribenko1-4/+11
large section flag (#73037)" This reverts commit 4bf8a688956a759b7b6b8d94f42d25c13c7af130. This commit seems to be breaking the semantics of the ObjectFile::isSectionText method, which breaks numba/llvmlite bindings.
2023-11-30Reland [X86] With large code model, put functions into .ltext with large ↵Arthur Eubanks1-11/+4
section flag (#73037) So that when mixing small and large text, large text stays out of the way of the rest of the binary. This is useful for mixing precompiled small code model object files and built-from-source large code model binaries so that the the text sections don't get merged. The reland fixes an issue where a function in the large code model would reference small data without GOTOFF.
2023-11-28Revert "[X86] With large code model, put functions into .ltext with large ↵Arthur Eubanks1-4/+11
section flag (#73037)" This reverts commit 38e435895779c6f0e6c47a171f3b300ad99828b3. May be culprit for https://lab.llvm.org/buildbot/#/builders/37/builds/28079/steps/9/logs/stdio.
2023-11-28[X86] With large code model, put functions into .ltext with large section ↵Arthur Eubanks1-11/+4
flag (#73037) So that when mixing small and large text, large text stays out of the way of the rest of the binary. This is useful for mixing precompiled small code model object files and built-from-source large code model binaries so that the the text sections don't get merged.
2023-10-31Revert "[Profile] Refactor profile correlation. (#70712)"Zequan Wu1-19/+0
This reverts commit 4b383d0af93136b80841fc140da0823dfc441dd4.
2023-10-31[Profile] Refactor profile correlation. (#70712)Zequan Wu1-0/+19
Refactor some code from https://github.com/llvm/llvm-project/pull/69493. Rebase of https://github.com/llvm/llvm-project/pull/69656 on top of main as it was messed up.
2023-10-18[ELF] Set large section flag for globals with an explicit section (#69396)Arthur Eubanks1-20/+23
An oversight in https://reviews.llvm.org/D148836 since this is a different code path.
2023-09-22[BasicBlockSections] Split cold parts of custom-section functions. (#66731)Rahman Lavaee1-13/+24
This PR makes `-basic-block-sections` handle functions with custom non-dot-text sections correctly. Cold parts of such functions must be placed in the same section (not in `.text.split`) but with a unique id.
2023-09-14[X86] Introduce a large data threshold for the medium code modelArthur Eubanks1-4/+4
Currently clang's medium code model treats all data as large, putting them in a large data section and using more expensive instruction sequences to access them. Following gcc's -mlarge-data-threshold, which allows putting data under a certain size in a normal data section as opposed to a large data section. This allows using cheaper code sequences to access some portion of data in the binary (which will be implemented in LLVM in a future patch). And under the medium codel mode, only put data above the large data threshold into large data sections, not all data. Reviewed By: MaskRay, rnk Differential Revision: https://reviews.llvm.org/D149288
2023-07-29[XCOFF] Do not put MergeableCStrings in their own sectionWael Yehia1-17/+0
The current implementation generates a csect with a ".rodata.str.x.y" prefix for a MergeableCString variable definition. However, a reference to such variable does not get the prefix in its name because there's not enough information in the containing IR. In particular, without seeing the initializer and absent of some other indicators, we cannot tell that the referenced variable is a null- terminated string. When the AIX codegen in llvm was being developed, the prefixing was copied from ELF without having the linker take advantage of the info. Currently, the AIX linker does not have the capability to merge MergeableCString variables. If such feature would ever get implemented, the contract between the linker and compiler would have to be reconsidered. Here's the before and after of this change: ``` @a = global i64 320255973571806, align 8 @strA = unnamed_addr constant [7 x i8] c"hello\0A\00", align 1 ;; Mergeable1ByteCString @strB = unnamed_addr constant [8 x i8] c"Blahah\0A\00", align 1 ;; Mergeable1ByteCString @strC = unnamed_addr constant [2 x i16] [i16 1, i16 0], align 2 ;; Mergeable2ByteCString @strD = unnamed_addr constant [2 x i16] [i16 1, i16 1], align 2 ;; !isMergeableCString @strE = external unnamed_addr constant [2 x i16], align 2 -fdata-sections: .text extern .rodata.str1.1strA .text extern strA 0 SD RO 0 SD RO .text extern .rodata.str1.1strB .text extern strB 0 SD RO 0 SD RO .text extern .rodata.str2.2strC ===> .text extern strC 0 SD RO 0 SD RO .text extern strD .text extern strD 0 SD RO 0 SD RO .data extern a .data extern a 0 SD RW 0 SD RW undef extern strE undef extern strE 0 ER UA 0 ER UA -fno-data-sections: .text unamex .rodata.str1.1 .text unamex .rodata 0 SD RO 0 SD RO .text extern strA .text extern strA 0 LD RO 0 LD RO .text extern strB .text extern strB 0 LD RO 0 LD RO .text unamex .rodata.str2.2 ===> .text extern strC 0 SD RO 0 LD RO .text extern strC .text extern strD 0 LD RO 0 LD RO .text unamex .rodata .data unamex .data 0 SD RO 0 SD RW .text extern strD .data extern a 0 LD RO 0 LD RW .data unamex .data undef extern strE 0 SD RW 0 ER UA .data extern a 0 LD RW undef extern strE 0 ER UA ``` Reviewed by: David Tenty, Fangrui Song Differential Revision: https://reviews.llvm.org/D156202
2023-07-25[XCOFF] Enable available_externally linkage for functions.esmeyi1-2/+2
Summary: D80642 added support for emitting AvailableExternally Linkage on AIX. However, an assertion of "Trying to get csect representation of this symbol but none was set." occurred when a function is declared as available_externally. This is due to we missing to generate a csect for the function. This patch fixes it. Reviewed By: hubert.reinterpretcast, shchenz Differential Revision: https://reviews.llvm.org/D156213 Signed-off-by: Esme Yi <esme.yi@ibm.com>
2023-07-24[clang][CodeGen] Introduce `-frecord-command-line` for MachOAntonio Frighetto1-0/+5
Allow clang driver command-line recording when targeting MachO object files as well. Reviewed-by: sgraenitz Differential Revision: https://reviews.llvm.org/D155716
2023-05-31[X86] Use "l" prefix for data sections under medium/large code modelArthur Eubanks1-7/+16
And also set the SHF_X86_64_LARGE section flag. gcc only uses the "l" prefix and SHF_X86_64_LARGE in the medium code model for data larger than -mlarge-data-threshold. But it seems more consistent to use it in the large code model as well in case separate parts of the binary aren't compiled with the large code model and also have a .data/.bss/.rodata section. Reviewed By: MaskRay, tkoeppe Differential Revision: https://reviews.llvm.org/D148836
2023-04-25[MachO] Disable atexit()-based lowering when LTO'ing kernel/kext codeJulian Lettner1-1/+6
The kernel and kext environments do not provide the `__cxa_atexit()` function, so we can't use it for lowering global module destructors. Unfortunately, just querying for "compiling for kernel/kext?" in the LTO pipeline isn't possible (kernel/kext identifier isn't part of the triple yet) so we need to pass down a CodeGen flag. rdar://93536111 Differential Revision: https://reviews.llvm.org/D148967
2023-03-23[AIX][CodeGen] Storage Locations for Constant PointersQiongsi Wu1-4/+16
This patch adds an `llc` option `-mroptr` to specify storage locations for constant pointers on AIX. When the `-mroptr` option is specified, constant pointers, virtual function tables, and virtual type tables are placed in read-only storage. Otherwise, by default, pointers, virtual function tables, and virtual type tables are placed are placed in read/write storage. https://reviews.llvm.org/D144190 enables the `-mroptr` option for `clang`. Reviewed By: hubert.reinterpretcast, stephenpeckham, myhsu, MaskRay, serge-sans-paille Differential Revision: https://reviews.llvm.org/D144189
2023-03-14Remove -lower-global-dtors-via-cxa-atexit flagJulian Lettner1-5/+1
Remove the `-lower-global-dtors-via-cxa-atexit` escape hatch introduced in D121736 [1], which switched the default lowering of global destructors on MachO to use `__cxa_atexit()` to avoid emitting deprecated `__mod_term_func` sections. I added this flag as an escape hatch in case the switch causes any problems. We didn't discover any problems so now we can remove it. [1] https://reviews.llvm.org/D121736 rdar://90277838 Differential Revision: https://reviews.llvm.org/D145715
2023-03-10MachO: support custom section names on global variablesTim Northover1-0/+14
These attributes have been accepted in ELF for a while, and are generated by Clang in some places, so it makes sense to support them on MachO too. https://reviews.llvm.org/D143173
2023-03-01[COFF][X86_64] Put jump table in .rdata for WindowsWei Xiao1-0/+17
Put jump table in .rdata for Windows to align with that for Linux. It can avoid loading the same code page into I$ and D$ simultaneously and thus favor performance. Differential Revision: https://reviews.llvm.org/D144701
2023-02-07[NFC][TargetParser] Remove llvm/ADT/Triple.hArchibald Elliott1-1/+1
I also ran `git clang-format` to get the headers in the right order for the new location, which has changed the order of other headers in two files.
2023-02-05[AArch64] Unconditionally use DW_EH_PE_indirect|DW_EH_PE_pcrel ↵Fangrui Song1-20/+8
personality/lsda/ttype encodings For -fno-pic, without DW_EH_PE_indirect, the personality routine pointer in a CIE needs an R_AARCH64_ABS64 relocation. In common configurations that `__gcc_personality_v0` is defined in a shared object, this will lead to a discouraged canonical PLT entry, or, if `ld.lld -z notext` (betwen D122459 and D143136), a dynamic R_AARCH64_ABS64 relocation with an incorrect offset: https://github.com/llvm/llvm-project/issues/60392 Since GCC uses DW_EH_PE_indirect for -fno-pic code (the behavior hasn't changed since the initial port in 2012), let's follow suit by simplifying the code. ( For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame offset > 2GiB. This is unneeded for small code model since "Max text segment size < 2GiB" but making `-fno-pic -mcmodel={tiny,small}` different seems unnecessary: the scenarios that uses both -fno-pic and C++ exceptions have been increasingly rare now, so there is little advantage optimizing for the little size saving with code complexity. ) --- Two clang/test/Interpreter tests would fail without 6747fc07d1aa94e22622e278e5a02ba70675ac9b ([ORC] Use JITLink as the default linker for LLJIT on Linux/arm64.) Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D143039
2023-02-04Revert "[AArch64] Unconditionally use DW_EH_PE_indirect|DW_EH_PE_pcrel ↵NAKAMURA Takumi1-8/+20
personality/lsda/ttype encodings" It causes failurs in clang-interpreter. This reverts commit 565a1fb1334b8cf510af1338cae3f50815a99f90, aka llvmorg-17-init-1048-g565a1fb1334b
2023-02-03[AArch64] Unconditionally use DW_EH_PE_indirect|DW_EH_PE_pcrel ↵Fangrui Song1-20/+8
personality/lsda/ttype encodings For -fno-pic, without DW_EH_PE_indirect, the personality routine pointer in a CIE needs an R_AARCH64_ABS64 relocation. In common configurations that `__gcc_personality_v0` is defined in a shared object, this will lead to a discouraged canonical PLT entry, or, if `ld.lld -z notext` (betwen D122459 and D143136), a dynamic R_AARCH64_ABS64 relocation with an incorrect offset: https://github.com/llvm/llvm-project/issues/60392 Since GCC uses DW_EH_PE_indirect for -fno-pic code (the behavior hasn't changed since the initial port in 2012), let's follow suit by simplifying the code. ( For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame offset > 2GiB. This is necessary for small code model since "Max text segment size < 2GiB" but it is unnecessary to make `-fno-pic -mcmodel={tiny,small}` different: The scenarios that uses both -fno-pic and C++ exceptions have been increasingly rare now, so there is little advantage optimizing for the little size saving with code complexity. ) Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D143039
2023-01-25Verifier: Add checks for associated metadataMatt Arsenault1-8/+1
Also add missing assembler test for the valid cases.
2023-01-11[XCOFF] handle the toc-data for object file generation.esmeyi1-4/+8
Summary: The toc-data feature has been supported for assembly file generation. This patch handles the toc-data for object file generation. Reviewed By: shchenz Differential Revision: https://reviews.llvm.org/D139516
2022-12-05[IR] llvm::Optional => std::optionalFangrui Song1-2/+2
Many llvm/IR/* files have been migrated by other contributors. This migrates most remaining files.
2022-11-24[Alignment][NFC] Use Align in MCStreamer::emitValueToAlignmentGuillaume Chatelet1-1/+1
Differential Revision: https://reviews.llvm.org/D138674
2022-11-09[SampleFDO] Persist profile staleness metrics into binarywlei1-0/+26
With https://reviews.llvm.org/D136627, now we have the metrics for profile staleness based on profile statistics, monitoring the profile staleness in real-time can help user quickly identify performance issues. For a production scenario, the build is usually incremental and if we want the real-time metrics, we should store/cache all the old object's metrics somewhere and pull them in a post-build time. To make it more convenient, this patch add an option to persist them into the object binary, the metrics can be reported right away by decoding the binary rather than polling the previous stdout/stderrs from a cache system. For implementation, it writes the statistics first into a new metadata section(llvm.stats) then encode into a special ELF `.llvm_stats` section. The section data is formatted as a list of key/value pair so that future statistics can be easily extended. This is also under a new switch(`-persist-profile-staleness`) In terms of size overhead, the metrics are computed at module level, so the size overhead should be small, measured on one of our internal service, it costs less than < 1MB for a 10GB+ binary. Reviewed By: wenlei Differential Revision: https://reviews.llvm.org/D136698
2022-10-08[LoongArch] Set correct encodings for DWARF exception handlingwanglei1-0/+8
This patch sets correct encodings for DWARF exception handling for LoongArch. Differential Revision: https://reviews.llvm.org/D134710
2022-08-16[Windows] Put init_seg(compiler/lib) in llvm.global_ctorsArthur Eubanks1-3/+16
Currently we treat initializers with init_seg(compiler/lib) as similar to any other init_seg, they simply have a global variable in the proper section (".CRT$XCC" for compiler/".CRT$XCL" for lib) and are added to llvm.used. However, this doesn't match with how LLVM sees normal (or init_seg(user)) initializers via llvm.global_ctors. This causes issues like incorrect init_seg(compiler) vs init_seg(user) ordering due to GlobalOpt evaluating constructors, and the ability to remove init_seg(compiler/lib) initializers at all. Currently we use 'A' for priorities less than 200. Use 200 for init_seg(compiler) (".CRT$XCC") and 400 for init_seg(lib) (".CRT$XCL"), which do not append the priority to the section name. Priorities between 200 and 400 use ".CRT$XCC${Priority}". This allows for some wiggle room for people/future extensions that want to add initializers between compiler and lib. Fixes #56922 Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D131910
2022-08-12[PowerPC] omit location attribute for TLS variable on AIXChen Zheng1-0/+7
TLS debug on AIX is not ready for now. The location generated in no-integrated-as mode is wrong and in integrated-as mode causes AIX linker error. Reviewed By: Esme Differential Revision: https://reviews.llvm.org/D130245
2022-08-08[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song1-1/+1
With C++17 there is no Clang pedantic warning or MSVC C5051.
2022-07-07[Metadata] Add 'exclude' metadata to add the exclude flags on globalsJoseph Huber1-3/+0
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
2022-07-07[Object] Add ELF section type for offloading objectsJoseph Huber1-0/+3
Currently we use the `.llvm.offloading` section to store device-side objects inside the host, creating a fat binary. The contents of these sections is currently determined by the name of the section while it should ideally be determined by its type. This patch adds the new `SHT_LLVM_OFFLOADING` section type to the ELF section types. Which should make it easier to identify this specific data format. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D129052
2022-06-10[MC] De-capitalize SwitchSection. NFCFangrui Song1-10/+10
Add SwitchSection to return switchSection. The API will be removed soon.
2022-06-08[Target] Remove `startswith` for adding `SHF_EXCLUDE` to offload sectionJoseph Huber1-1/+1
Summary: We use the special section name `.llvm.offloading` to store device imagees in the host object file. We want these to be stripped by the linker as they are not used after linking so we use the `SHF_EXCLUDE` flag to instruct the linker to drop them. We used to do this for all sections that started with `.llvm.offloading` when we encoded metadata in the section name itself. Now we embed a special binary containing the metadata, we should only add the flag on this name specifically.
generated by cgit v1.1 at 2025-09-29 15:29:23 +0000