summaryrefslogtreecommitdiff
path: root/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Use the existing llvm-plugins option for both legacy and new pm registrationAxel Cohen2021-12-131-4/+4
|
* Add a codegen option to allow loading LLVM pass pluginsAxel Cohen2021-12-131-1/+17
|
* PassWrapper: additional sanitizer update to match clangKrasimir Georgiev2021-11-111-1/+0
| | | | | | This happened later in the stream than the other changes, but the fix is overlapping. Fix taken from a55c4ec1cee7683d9095327d9d33e7137ec25292 in LLVM.
* Didn't mean to invert this boolean.Augie Fackler2021-11-091-1/+1
|
* rustc_llvm: update PassWrapper for recent LLVMAugie Fackler2021-11-091-6/+9
| | | | | | | Now AddressSanitizerOptions is a struct, but at least the change was tiny. r? nikic
* Initialize LLVM time trace profiler on each code generation threadTomasz Miąsko2021-11-051-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.
* Rollup merge of #89581 - jblazquez:master, r=Mark-SimulacrumMatthias Krüger2021-10-251-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.
| * Add -Z no-unique-section-names to reduce ELF header bloat.Javier Blazquez2021-10-111-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.
* | Update the minimum external LLVM to 12Josh Stone2021-10-221-74/+2
| |
* | Update the minimum external LLVM to 11Josh Stone2021-10-221-93/+0
| |
* | RustWrapper: adapt for an LLVM API changeKrasimir Georgiev2021-10-181-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.
* | Enable AutoFDO.Michael Benfield2021-10-061-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.
* PassWrapper: handle function rename from upstream D36850Augie Fackler2021-09-271-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.
* Use correct pipeline for LTO at O0Nikita Popov2021-09-251-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.
* Rollup merge of #89041 - sticnarf:sticnarf/fat-lto-dwarf, r=nagisathe84722021-09-221-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.
| * Work around invalid DWARF bugs for fat LTOYilin Chen2021-09-171-2/+2
| | | | | | | | Signed-off-by: Yilin Chen <sticnarf@gmail.com>
* | compiler/rustc_llvm: Enable M68k LLVM targetJohn Paul Adrian Glaubitz2021-09-171-0/+7
|/
* PassWrapper: these two lines shouldn't have been ifdef'dAugie Fackler2021-09-161-2/+2
|
* PassWrapper: handle separate Module*SanitizerPassAugie Fackler2021-09-161-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
* PassWrapper: adapt for LLVM 14 changesAugie Fackler2021-08-191-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.
* PassWrapper: handle move of OptimizationLevel class out of PassBuilderAugie Fackler2021-08-061-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.
* Auto merge of #85416 - durin42:llvm-catchup-may-2021, r=nagisabors2021-05-211-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.
| * PassWrapper: update for LLVM change D102093Augie Fackler2021-05-171-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.
* | Support -C passes in NewPMNikita Popov2021-05-081-2/+12
| | | | | | | | | | And report an error if parsing the additional pass pipeline fails. Threading through the error accounts for most of the changes here.
* | Explicitly register GCOV profiling pass as wellNikita Popov2021-05-081-1/+11
| |
* | Explicitly register instrprof passNikita Popov2021-05-081-1/+11
|/ | | | | Don't use "passes" for this purpose, explicitly insert it into the correct place in the pipeline instead.
* Replace llvm::sys::fs::F_None with llvm::sys::fs::OF_NoneFangrui Song2021-04-291-3/+3
| | | | | The former is deprecated. OF_None has been available in LLVM since 2018-06.
* Categorize and explain target features supportMatt Ickstadt2021-04-091-18/+15
|
* Auto merge of #83387 - cuviper:min-llvm-10, r=nagisabors2021-03-251-41/+0
|\ | | | | | | | | | | Update the minimum external LLVM to 10 r? `@nikic`
| * Update the minimum external LLVM to 10Josh Stone2021-03-221-41/+0
| |
* | cleanup: add some comments per review feedbackAugie Fackler2021-03-221-0/+3
| |
* | fix: I meant LLVM version 13, not 12Augie Fackler2021-03-191-1/+1
| |
* | llvm-wrapper: adapt to function signature change of ↵Augie Fackler2021-03-161-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.
* Auto merge of #83044 - kubo39:set-llvm-code-model, r=nikicbors2021-03-141-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
| * Add support for storing code model to LLVM module IRHiroki Noda2021-03-121-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
* | Support merge_functions option in NewPM since LLVM >= 12Hiroki Noda2021-03-121-2/+6
|/ | | | | now we can pass this flag since https://reviews.llvm.org/D93002 has been merged.
* Schedule ThinLTOBuffer passes again after sanitizer passesNikita Popov2021-03-031-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.
* Support LLVM 12 in rustcNikita Popov2021-02-281-22/+97
|
* HWASan supportTri Vo2021-02-071-0/+26
|
* llvm: update ffi bindings for split dwarfDavid Wood2020-12-161-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>
* fully exploited the dropped support of LLVM 8DevJPM2020-11-121-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
* Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuseAaron Hill2020-09-171-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.
* Move `rustllvm` into `rustc_llvm`Vadim Petrochenkov2020-09-091-0/+1655
View Lorry Controller Status