about summary refs log tree commit diff
path: root/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp
AgeCommit message (Collapse)AuthorLines
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