about summary refs log tree commit diff
path: root/compiler/rustc_llvm/llvm-wrapper
AgeCommit message (Collapse)AuthorLines
2021-08-04Replace LLVMConstInBoundsGEP with LLVMConstInBoundsGEP2*Tomasz Miąsko-0/+10
A custom reimplementation of LLVMConstInBoundsGEP2 is used, since the LLVM contains a declaration of LLVMConstInBoundsGEP2 but not the implementation.
2021-07-09Pass type when creating atomic loadNikita Popov-4/+3
Instead of determining it from the pointer type, explicitly pass the type to load.
2021-06-04Add first cut of functionality for #58713: support for #[link(kind = ↵Richard Cobbe-0/+52
"raw-dylib")]. This does not yet support #[link_name] attributes on functions, the #[link_ordinal] attribute, #[link(kind = "raw-dylib")] on extern blocks in bin crates, or stdcall functions on 32-bit x86.
2021-06-04rustc: Store metadata-in-rlibs in object filesAlex Crichton-35/+0
This commit updates how rustc compiler metadata is stored in rlibs. Previously metadata was stored as a raw file that has the same format as `--emit metadata`. After this commit, however, the metadata is encoded into a small object file which has one section which is the contents of the metadata. The motivation for this commit is to fix a common case where #83730 arises. The problem is that when rustc crates a `dylib` crate type it needs to include entire rlib files into the dylib, so it passes `--whole-archive` (or the equivalent) to the linker. The problem with this, though, is that the linker will attempt to read all files in the archive. If the metadata file were left as-is (today) then the linker would generate an error saying it can't read the file. The previous solution was to alter the rlib just before linking, creating a new archive in a temporary directory which has the metadata file removed. This problem from before this commit is now removed if the metadata file is stored in an object file that the linker can read. The only caveat we have to take care of is to ensure that the linker never actually includes the contents of the object file into the final output. We apply similar tricks as the `.llvmbc` bytecode sections to do this. This involved changing the metadata loading code a bit, namely updating some of the LLVM C APIs used to use non-deprecated ones and fiddling with the lifetimes a bit to get everything to work out. Otherwise though this isn't intended to be a functional change really, only that metadata is stored differently in archives now. This should end up fixing #83730 because by default dylibs will no longer have their rlib dependencies "altered" meaning that split-debuginfo will continue to have valid paths pointing at the original rlibs. (note that we still "alter" rlibs if LTO is enabled to remove Rust object files and we also "alter" for the #[link(cfg)] feature, but that's rarely used). Closes #83730
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-22RustWrapper: work around unification of diagnostic handlersAugie Fackler-1/+11
This lets me build against llvm/main as of March 23rd, 2021. I'm not entirely sure this is _correct_, but it appears to be functionally identical to what was done in LLVM: existing callsites of setInlineAsmDiagnosticHandler were moved to SetDiagnosticHandler() on the context object, which we already set up in both places that we called setInlineAsmDiagnosticHandler().
2021-04-17Don't set `fast`(-math) for certain simd opsSimonas Kazlauskas-2/+4
`fast-math` implies things like functions not being able to accept as an argument or return as a result, say, `inf` which made these functions confusingly named or behaving incorrectly, depending on how you interpret it. Since the time when these intrinsics have been implemented the intrinsics user's (stdsimd) approach has changed significantly and so now it is required that these intrinsics operate normally rather than in "whatever" way. Fixes #84268
2021-04-09Categorize and explain target features supportMatt Ickstadt-18/+15
2021-04-03Manually set dso_local when its valid to do soSimonas Kazlauskas-0/+4
This should have no real effect in most cases, as e.g. `hidden` visibility already implies `dso_local` (or at least LLVM IR does not preserve the `dso_local` setting if the item is already `hidden`), but it should fix `-Crelocation-model=static` and improve codegen in executables. Note that this PR does not exhaustively port the logic in [clang]. Only the obviously correct portion and what is necessary to fix a regression from LLVM 12 that relates to `-Crelocation_model=static`. Fixes #83335 [clang]: https://github.com/llvm/llvm-project/blob/3001d080c813da20b329303bf8f45451480e5905/clang/lib/CodeGen/CodeGenModule.cpp#L945-L1039
2021-03-25Auto merge of #83387 - cuviper:min-llvm-10, r=nagisabors-83/+0
Update the minimum external LLVM to 10 r? `@nikic`
2021-03-24LLVMWrapper: attractive nuisance macrosAugie Fackler-7/+0
THis came up in the review of #83425: it's hard to imagine a use of LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble when a point release gets created, so let's just discard them to prevent the issue.
2021-03-22cleanup: add some comments per review feedbackAugie Fackler-0/+6
2021-03-22Update the minimum external LLVM to 10Josh Stone-83/+0
2021-03-19fix: I meant LLVM version 13, not 12Augie Fackler-3/+3
2021-03-16llvm-wrapper: pass std::string instead of StringRefAugie Fackler-0/+7
LLVM change 5fbd1a333aa1a0b70903d036b98ea56c51ae5224 modified this function to want std::string instead of StringRef, which is easily done.
2021-03-16llvm-wrapper: add alignment argument to CreateAtomicCmpXchgAugie Fackler-0/+6
As far as I can tell what we've been getting is llvm::MaybeAlign(), so just use that for now. This is required sometime after 24539f1ef2471d07bd87f833cb0288fc0f251f4b.
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-03-01Mark pure asm as willreturnNikita Popov-0/+3
2021-03-01Don't directly expose coverage::CounterMappingRegion via FFINikita Popov-2/+22
The definition of this struct changes in LLVM 12 due to the addition of branch coverage support. To avoid future mismatches, declare our own struct and then convert between them.
2021-02-28Support LLVM 12 in rustcNikita Popov-26/+146
2021-02-07HWASan supportTri Vo-0/+29
2021-02-02Add a new ABI to support cmse_nonsecure_callHugues de Valon-0/+8
This commit adds a new ABI to be selected via `extern "C-cmse-nonsecure-call"` on function pointers in order for the compiler to apply the corresponding cmse_nonsecure_call callsite attribute. For Armv8-M targets supporting TrustZone-M, this will perform a non-secure function call by saving, clearing and calling a non-secure function pointer using the BLXNS instruction. See the page on the unstable book for details. Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
2021-01-14Use probe-stack=inline-asm in LLVM 11+Erik Desjardins-0/+2
2021-01-13Remove the unused context from CreateDebugLocationJosh Stone-4/+2
This went unused in commit 88d874de6395, part of #68965.
2020-12-16llvm: update ffi bindings for split dwarfDavid Wood-6/+25
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-25Improved version checkRich Kadel-3/+2
2020-11-24Check for LLVM 11+ when using `-Z instrument-coverage`Rich Kadel-0/+8
* `rustc` should now compile under LLVM 9 or 10 * Compiler generates an error if `-Z instrument-coverage` is specified but LLVM version is less than 11 * Coverage tests that require `-Z instrument-coverage` and run codegen should be skipped if LLVM version is less than 11
2020-11-23Upgrades the coverage map to Version 4Rich Kadel-17/+32
Changes the coverage map injected into binaries compiled with `-Zinstrument-coverage` to LLVM Coverage Mapping Format, Version 4 (from Version 3). Note, binaries compiled with this version will require LLVM tools from at least LLVM Version 11.
2020-11-12fully exploited the dropped support of LLVM 8DevJPM-46/+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-11-03Rollup merge of #77950 - arlosi:sha256, r=eddybMara Bos-0/+5
Add support for SHA256 source file hashing Adds support for `-Z src-hash-algorithm sha256`, which became available in LLVM 11. Using an older version of LLVM will cause an error `invalid checksum kind` if the hash algorithm is set to sha256. r? `@eddyb` cc #70401 `@est31`
2020-11-01Auto merge of #78531 - cuviper:unwrap-metadata, r=tmandrybors-1/+1
rustc_llvm: unwrap LLVMMetadataRef before casting Directly casting the opaque pointer was [reported] to cause an "incomplete type" error with GCC 9.3: ``` llvm-wrapper/RustWrapper.cpp:939:31: required from here /usr/include/c++/9.3/type_traits:1301:12: error: invalid use of incomplete type 'struct LLVMOpaqueMetadata' 1301 | struct is_base_of | ^~~~~~~~~~ In file included from [...]/rust/src/llvm-project/llvm/include/llvm-c/BitReader.h:23, from llvm-wrapper/LLVMWrapper.h:1, from llvm-wrapper/RustWrapper.cpp:1: [...]/rust/src/llvm-project/llvm/include/llvm-c/Types.h:89:16: note: forward declaration of 'struct LLVMOpaqueMetadata' 89 | typedef struct LLVMOpaqueMetadata *LLVMMetadataRef; | ^~~~~~~~~~~~~~~~~~ ``` [reported]: https://zulip-archive.rust-lang.org/182449tcompilerhelp/12215halprustcllvmbuildfail.html#214915124 A simple `unwrap` fixes the issue. r? `@eddyb`
2020-10-29rustc_llvm: unwrap LLVMMetadataRef before castingJosh Stone-1/+1
Directly casting the opaque pointer was [reported] to cause an "incomplete type" error with GCC 9.3: ``` llvm-wrapper/RustWrapper.cpp:939:31: required from here /usr/include/c++/9.3/type_traits:1301:12: error: invalid use of incomplete type 'struct LLVMOpaqueMetadata' 1301 | struct is_base_of | ^~~~~~~~~~ In file included from [...]/rust/src/llvm-project/llvm/include/llvm-c/BitReader.h:23, from llvm-wrapper/LLVMWrapper.h:1, from llvm-wrapper/RustWrapper.cpp:1: [...]/rust/src/llvm-project/llvm/include/llvm-c/Types.h:89:16: note: forward declaration of 'struct LLVMOpaqueMetadata' 89 | typedef struct LLVMOpaqueMetadata *LLVMMetadataRef; | ^~~~~~~~~~~~~~~~~~ ``` [reported]: https://zulip-archive.rust-lang.org/182449tcompilerhelp/12215halprustcllvmbuildfail.html#214915124 A simple `unwrap` fixes the issue.
2020-10-29Rollup merge of #78462 - danielframpton:fixnullisa, r=nagisaJonas Schievink-1/+1
Use unwrapDIPtr because the Scope may be null. I ran into an assertion when using debug information on Windows with LLVM assertions enabled. It seems like we are using unwrap here (which in turn calls isa and requires the pointer to be non-null) but we expect the value to be null because that is what we are passing from rustc. This change uses unwrapDIPtr which explicitly allows nullptr. The FFI prototype for this method on the rust side has the `LLVMMetadataRef` parameter as `Scope: Option<&'a DIScope>`, and we always pass `None` when `msvc_like_names` is true.
2020-10-27Use unwrapDIPtr because the Scope may be passed as NoneDaniel Frampton-1/+1
2020-10-21rustc_codegen_llvm: avoid converting between DILocation and Value.Eduard-Mihai Burtescu-4/+4
2020-10-21rustc_codegen_llvm: move DISubprogram creation to a dbg_scope_fn method.Eduard-Mihai Burtescu-2/+3
2020-10-14Add support for SHA256 source file hashing for LLVM 11+.Arlo Siemsen-0/+5
2020-10-11Auto merge of #76859 - Aaron1011:fix/llvm-cgu-reuse, r=davidtwco,nikicbors-3/+36
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse 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-30Update LLVM and add Unsupported diagnosticHugues de Valon-0/+3
Secure entry functions do not support if arguments are passed on the stack. An "unsupported" diagnostic will be emitted by LLVM if that is the case. This commits adds support in Rust for that diagnostic so that an error will be output if that is the case! Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
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/+3857
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-11-11 06:54:56 +0000