about summary refs log tree commit diff
path: root/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp
AgeCommit message (Collapse)AuthorLines
2022-04-20Stub out more PassManagerBuilder functionsNikita Popov-1/+52
2022-04-20Stub out various legacy PM functions with LLVM 15Nikita Popov-0/+44
2022-04-10Respect -Z verify-llvm-ir and other flags that add extra passes when ↵Luqman Aden-0/+7
combined with -C no-prepopulate-passes in the new LLVM Pass Manager.
2022-01-14Remove LLVMRustMarkAllFunctionsNounwindAmanieu d'Antras-19/+0
This was originally introduced in #10916 as a way to remove all landing pads when performing LTO. However this is no longer necessary today since rustc properly marks all functions and call-sites as nounwind where appropriate. In fact this is incorrect in the presence of `extern "C-unwind"` which must create a landing pad when compiled with `-C panic=abort` so that foreign exceptions are caught and properly turned into aborts.
2021-12-13Use the existing llvm-plugins option for both legacy and new pm registrationAxel Cohen-4/+4
2021-12-13Add a codegen option to allow loading LLVM pass pluginsAxel Cohen-1/+17
2021-11-11PassWrapper: additional sanitizer update to match clangKrasimir Georgiev-1/+0
This happened later in the stream than the other changes, but the fix is overlapping. Fix taken from a55c4ec1cee7683d9095327d9d33e7137ec25292 in LLVM.
2021-11-09Didn't mean to invert this boolean.Augie Fackler-1/+1
2021-11-09rustc_llvm: update PassWrapper for recent LLVMAugie Fackler-6/+9
Now AddressSanitizerOptions is a struct, but at least the change was tiny. r? nikic
2021-11-05Initialize LLVM time trace profiler on each code generation threadTomasz Miąsko-0/+4
In https://reviews.llvm.org/D71059 LLVM 11, the time trace profiler was extended to support multiple threads. `timeTraceProfilerInitialize` creates a thread local profiler instance. When a thread finishes `timeTraceProfilerFinishThread` moves a thread local instance into a global collection of instances. Finally when all codegen work is complete `timeTraceProfilerWrite` writes data from the current thread local instance and the instances in global collection of instances. Previously, the profiler was intialized on a single thread only. Since this thread performs no code generation on its own, the resulting profile was empty. Update LLVM codegen to initialize & finish time trace profiler on each code generation thread.
2021-10-25Rollup merge of #89581 - jblazquez:master, r=Mark-SimulacrumMatthias Krüger-0/+2
Add -Z no-unique-section-names to reduce ELF header bloat. This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions. By default, when enabling function sections (which is the default for most targets), the LLVM backend will generate different section names for each function. For example, a function `func` would generate a section called `.text.func`. Normally this is fine because the linker will merge all those sections into a single one in the binary. However, starting with [LLVM 12](https://github.com/llvm/llvm-project/commit/ee5d1a04), the backend will also generate unique section names for exception handling, resulting in thousands of `.gcc_except_table.*` sections ending up in the final binary because some linkers like LLD don't currently merge or strip these EH sections (see discussion [here](https://reviews.llvm.org/D83655)). This can bloat the ELF headers and string table significantly in binaries that contain many functions. The new option is analogous to Clang's `-fno-unique-section-names`, and instructs LLVM to generate the same `.text` and `.gcc_except_table` section for each function, resulting in a smaller final binary. The motivation to add this new option was because we have a binary that ended up with so many ELF sections (over 65,000) that it broke some existing ELF tools, which couldn't handle so many sections. Here's our old binary: ``` $ readelf --sections old.elf | head -1 There are 71746 section headers, starting at offset 0x2a246508: $ readelf --sections old.elf | grep shstrtab [71742] .shstrtab STRTAB 0000000000000000 2977204c ad44bb 00 0 0 1 ``` That's an 11MB+ string table. Here's the new binary using this option: ``` $ readelf --sections new.elf | head -1 There are 43 section headers, starting at offset 0x29143ca8: $ readelf --sections new.elf | grep shstrtab [40] .shstrtab STRTAB 0000000000000000 29143acc 0001db 00 0 0 1 ``` The whole binary size went down by over 20MB, which is quite significant.
2021-10-22Update the minimum external LLVM to 12Josh Stone-74/+2
2021-10-22Update the minimum external LLVM to 11Josh Stone-93/+0
2021-10-18RustWrapper: adapt for an LLVM API changeKrasimir Georgiev-0/+5
No functional changes intended. The LLVM commit https://github.com/llvm/llvm-project/commit/89b57061f7b769e9ea9bf6ed686e284f3e55affe moved TargetRegistry.(h|cpp) from Support to MC. This adapts RustWrapper accordingly.
2021-10-11Add -Z no-unique-section-names to reduce ELF header bloat.Javier Blazquez-0/+2
This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions. By default, when enabling function sections (which is the default for most targets), the LLVM backend will generate different section names for each function. For example, a function "func" would generate a section called ".text.func". Normally this is fine because the linker will merge all those sections into a single one in the binary. However, starting with LLVM 12 (llvm/llvm-project@ee5d1a0), the backend will also generate unique section names for exception handling, resulting in thousands of ".gcc_except_table.*" sections ending up in the final binary because some linkers don't currently merge or strip these EH sections. This can bloat the ELF headers and string table significantly in binaries that contain many functions. The new option is analogous to Clang's -fno-unique-section-names, and instructs LLVM to generate the same ".text" and ".gcc_except_table" section for each function, resulting in smaller object files and potentially a smaller final binary.
2021-10-06Enable AutoFDO.Michael Benfield-9/+21
This largely involves implementing the options debug-info-for-profiling and profile-sample-use and forwarding them on to LLVM. AutoFDO can be used on x86-64 Linux like this: rustc -O -Cdebug-info-for-profiling main.rs -o main perf record -b ./main create_llvm_prof --binary=main --out=code.prof rustc -O -Cprofile-sample-use=code.prof main.rs -o main2 Now `main2` will have feedback directed optimization applied to it. The create_llvm_prof tool can be obtained from this github repository: https://github.com/google/autofdo Fixes #64892.
2021-09-27PassWrapper: handle function rename from upstream D36850Augie Fackler-0/+4
thinLTOResolvePrevailingInModule became thinLTOFinalizeInModule and gained the ability to propagate noRecurse and noUnwind function attributes. I ran codegen tests with it both on and off, as the upstream patch uses it in both modes, and the tests pass both ways. Given that, it seemed reasonable to go ahead and let the propagation be enabled in rustc, and see what happens. See https://reviews.llvm.org/D36850 for more examples of how the new version of the function gets used.
2021-09-25Use correct pipeline for LTO at O0Nikita Popov-1/+4
Unlike the pre-link piplines, the LTO pipelines do support O0, and using them is required to avoid leaving behind undefined references for the linker.
2021-09-22Rollup merge of #89041 - sticnarf:sticnarf/fat-lto-dwarf, r=nagisathe8472-2/+2
Work around invalid DWARF bugs for fat LTO This PR applies the same workaround in #46772 to fat LTO. It seems to fix the bug reported in https://github.com/rust-lang/rust/issues/66118#issuecomment-917434036.
2021-09-17Work around invalid DWARF bugs for fat LTOYilin Chen-2/+2
Signed-off-by: Yilin Chen <sticnarf@gmail.com>
2021-09-17compiler/rustc_llvm: Enable M68k LLVM targetJohn Paul Adrian Glaubitz-0/+7
2021-09-16PassWrapper: these two lines shouldn't have been ifdef'dAugie Fackler-2/+2
2021-09-16PassWrapper: handle separate Module*SanitizerPassAugie Fackler-0/+8
Change ab41eef9aca3 in LLVM split MemorySanitizerPass into MemorySanitizerPass for functions and ModuleMemorySanitizerPass for modules. There's a related change for ThreadSanitizerPass, and in here since we're using a ModulePassManager I only add the module flavor of the pass on LLVM 14. r? @nikic cc @nagisa
2021-08-19PassWrapper: adapt for LLVM 14 changesAugie Fackler-0/+15
These API changes appear to have all taken place in https://reviews.llvm.org/D105007, which moved HWAddressSanitizerPass and AddressSanitizerPass to only accept their options type as a ctor argument instead of the sequence of bools etc. This required a couple of parameter additions, which I made match the default prior to the mentioned upstream LLVM change. This patch restores rustc to building (though not quite passing all tests, I've mailed other patches for those issues) against LLVM HEAD.
2021-08-06PassWrapper: handle move of OptimizationLevel class out of PassBuilderAugie Fackler-27/+31
This is the first build break of the LLVM 14 cycle, and was caused by https://reviews.llvm.org/D107025. Mercifully an easy fix.
2021-05-21Auto merge of #85416 - durin42:llvm-catchup-may-2021, r=nagisabors-1/+12
PassWrapper: update for LLVM change D102093 In https://reviews.llvm.org/D102093 lots of things stopped taking the DebugLogging boolean parameter. Mercifully we appear to always set DebugPassManager to false, so I don't think we're losing anything by not passing this parameter.
2021-05-17PassWrapper: update for LLVM change D102093Augie Fackler-1/+12
In https://reviews.llvm.org/D102093 lots of things stopped taking the DebugLogging boolean parameter. Mercifully we appear to always set DebugPassManager to false, so I don't think we're losing anything by not passing this parameter.
2021-05-08Support -C passes in NewPMNikita Popov-2/+12
And report an error if parsing the additional pass pipeline fails. Threading through the error accounts for most of the changes here.
2021-05-08Explicitly register GCOV profiling pass as wellNikita Popov-1/+11
2021-05-08Explicitly register instrprof passNikita Popov-1/+11
Don't use "passes" for this purpose, explicitly insert it into the correct place in the pipeline instead.
2021-04-29Replace llvm::sys::fs::F_None with llvm::sys::fs::OF_NoneFangrui Song-3/+3
The former is deprecated. OF_None has been available in LLVM since 2018-06.
2021-04-09Categorize and explain target features supportMatt Ickstadt-18/+15
2021-03-25Auto merge of #83387 - cuviper:min-llvm-10, r=nagisabors-41/+0
Update the minimum external LLVM to 10 r? `@nikic`
2021-03-22cleanup: add some comments per review feedbackAugie Fackler-0/+3
2021-03-22Update the minimum external LLVM to 10Josh Stone-41/+0
2021-03-19fix: I meant LLVM version 13, not 12Augie Fackler-1/+1
2021-03-16llvm-wrapper: adapt to function signature change of ↵Augie Fackler-1/+6
thinLTOResolvePrevailingInIndex This changed in 54fb3ca96e261f7107cb1b5778c34cb0e0808be6 - I'm not entirely sure it's correct that we're leaving config empty, but the one case in LLVM that looked similar did that.
2021-03-14Auto merge of #83044 - kubo39:set-llvm-code-model, r=nikicbors-0/+8
Add support for storing code model to LLVM module IR This patch avoids undefined behavior by linking different object files. Also this would it could be propagated properly to LTO. See https://reviews.llvm.org/D52322 and https://reviews.llvm.org/D52323. This patch is based on https://github.com/rust-lang/rust/pull/74002
2021-03-12Add support for storing code model to LLVM module IRHiroki Noda-0/+8
This patch avoids undefined behavior by linking different object files. Also this would it could be propagated properly to LTO. See https://reviews.llvm.org/D52322 and https://reviews.llvm.org/D52323. This patch is based on https://github.com/rust-lang/rust/pull/74002
2021-03-12Support merge_functions option in NewPM since LLVM >= 12Hiroki Noda-2/+6
now we can pass this flag since https://reviews.llvm.org/D93002 has been merged.
2021-03-03Schedule ThinLTOBuffer passes again after sanitizer passesNikita Popov-1/+6
This works around a design defect in the LLVM 12 pass builder implementation. In LLVM 13, the PreLink ThinLTO pipeline properly respects the OptimizerLastEPCallbacks.
2021-02-28Support LLVM 12 in rustcNikita Popov-22/+97
2021-02-07HWASan supportTri Vo-0/+26
2020-12-16llvm: update ffi bindings for split dwarfDavid Wood-4/+22
This commit modifies the FFI bindings to LLVM required for Split DWARF support in rustc. In particular: - `addPassesToEmitFile`'s wrapper, `LLVMRustWriteOutputFile` now takes a `DwoPath` `const char*`. When disabled, `nullptr` should be provided which will preserve existing behaviour. When enabled, the path to the `.dwo` file should be provided. - `createCompileUnit`'s wrapper, `LLVMRustDIBuilderCreateCompileUnit` now has two additional arguments, for the `DWOId` and to enable `SplitDebugInlining`. `DWOId` should always be zero. - `createTargetMachine`'s wrapper, `LLVMRustCreateTargetMachine` has an additional argument which should be provided the path to the `.dwo` when enabled. Signed-off-by: David Wood <david@davidtw.co>
2020-11-12fully exploited the dropped support of LLVM 8DevJPM-30/+2
This commit grepped for LLVM_VERSION_GE, LLVM_VERSION_LT, get_major_version and min-llvm-version and statically evaluated every expression possible (and sensible) assuming that the LLVM version is >=9 now
2020-09-17Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuseAaron Hill-3/+36
During incremental ThinLTO compilation, we attempt to re-use the optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do so. Up until now, 'safe' has meant that the set of modules that our current modules imports from/exports to is unchanged from the previous compilation session. See PR #67020 and PR #71131 for more details. However, this turns out be insufficient to guarantee that it's safe to reuse the post-LTO module (i.e. that optimizing the pre-LTO module would produce the same result). When LLVM optimizes a module during ThinLTO, it may look at other information from the 'module index', such as whether a (non-imported!) global variable is used. If this information changes between compilation runs, we may end up re-using an optimized module that (for example) had dead-code elimination run on a function that is now used by another module. Fortunately, LLVM implements its own ThinLTO module cache, which is used when ThinLTO is performed by a linker plugin (e.g. when clang is used to compile a C proect). Using this cache directly would require extensive refactoring of our code - but fortunately for us, LLVM provides a function that does exactly what we need. The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash from all data that might influence the result of ThinLTO on a module. In addition to the module imports/exports that we manually track, it also hashes information about global variables (e.g. their liveness) which might be used during optimization. By using this function, we shouldn't have to worry about new LLVM passes breaking our module re-use behavior. In LLVM, the output of this function forms part of the filename used to store the post-ThinLTO module. To keep our current filename structure intact, this PR just writes out the mapping 'CGU name -> Hash' to a file. To determine if a post-LTO module should be reused, we compare hashes from the previous session. This should unblock PR #75199 - by sheer chance, it seems to have hit this issue due to the particular CGU partitioning and optimization decisions that end up getting made.
2020-09-09Move `rustllvm` into `rustc_llvm`Vadim Petrochenkov-0/+1655
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-11-08 09:33:31 +0000