summaryrefslogtreecommitdiff
path: root/compiler/rustc_llvm/llvm-wrapper
Commit message (Collapse)AuthorAgeFilesLines
...
* | | Use LLVM for getting symbols from COFF bigobj filesbjorn32022-11-261-10/+24
| | |
* | | Rewrite LLVM's archive writer in Rustbjorn32022-11-262-0/+86
|/ / | | | | | | This allows it to be used by other codegen backends
* | [llvm-wrapper] adapt for LLVM API changeKrasimir Georgiev2022-11-251-0/+4
| | | | | | | | | | Adapt for the LLVM API changes from https://github.com/llvm/llvm-project/commit/721f975d3518403502f770ce11f3f02509b30c5b#diff-5a347903b8412ed1b1b1948c3fce47f9a6ff05dc70bfaeedb6d06b622e399d91.
* | Rollup merge of #104517 - dfordivam:patch-1, r=cuviperMatthias Krüger2022-11-241-1/+1
|\ \ | |/ |/| | | | | | | | | | | Throw error on failure in loading llvm-plugin The following code silently ignores the error as the `LLVMRustSetLastError` only tracks one error at a time. At all other places where `LLVMRustSetLastError` is used the code immediately returns. https://github.com/rust-lang/rust/blob/251831ece9601d64172127b6caae9087358c2386/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L801-L804
| * Throw error on failure in loading llvm-pluginDivam Narula2022-11-171-1/+1
| |
* | Auto merge of #102717 - beetrees:repr128-c-style-debuginfo, r=nagisabors2022-11-211-2/+3
|\ \ | |/ |/| | | | | | | | | | | Pass 128-bit C-style enum enumerator values to LLVM Pass the full 128 bits of C-style enum enumerators through to LLVM. This means that debuginfo for C-style repr128 enums is now emitted correctly for DWARF platforms (as compared to not being correctly emitted on any platform). Tracking issue: #56071
| * Pass 128-bit C-style enum enumerator values to LLVMbeetrees2022-10-091-2/+3
| |
* | Introduce composite debuginfo.Camille GILLOT2022-11-151-0/+4
| |
* | [llvm-wrapper] adapt for LLVM API changeKrasimir Georgiev2022-11-141-1/+1
| |
* | LLVM 16: Switch to using MemoryEffectsTim Neumann2022-11-042-3/+40
| |
* | llvm-16: Don't initialize removed legacy passesMatthew Maurer2022-10-251-0/+2
|/ | | | | LLVM removed initialization for legacy passes: https://reviews.llvm.org/D136615
* Avoid LLVM-deprecated `Optional::hasValue`Josh Stone2022-09-261-1/+1
| | | | | | | LLVM 15 added `Optional::has_value`, and LLVM `main` (16) has deprecated `hasValue`. However, its `explicit operator bool` does the same thing, and was added long ago, so we can use that across our full LLVM range of compatibility.
* Rollup merge of #101997 - cuviper:drop-legacy-pm, r=nikicfee1-dead2022-09-252-257/+7
|\ | | | | | | | | | | | | | | | | Remove support for legacy PM This removes support for optimizing with LLVM's legacy pass manager, as well as the unstable `-Znew-llvm-pass-manager` option. We have been defaulting to the new PM since LLVM 13 (except for s390x that waited for 14), and LLVM 15 removed support altogether. The only place we still use the legacy PM is for writing the output file, just like `llc` does. cc #74705 r? ``@nikic``
| * Use the helper for internalizing with new PMJosh Stone2022-09-181-5/+2
| |
| * Never use legacy PM for writing bitcodeJosh Stone2022-09-182-18/+4
| |
| * Remove support for LLVM's legacy pass managerJosh Stone2022-09-181-234/+1
| |
* | Use LLVM C-API to build atomic cmpxchg and fenceJosh Stone2022-09-181-39/+0
|/
* Introduce a fallible variant of LLVMConstIntGetZExtValueTomasz Miąsko2022-09-091-0/+8
| | | | which verifies that a constant bit width is within 64 bits or fails.
* Rollup merge of #99207 - 5225225:msan-eager-checks, r=jackh726Matthias Krüger2022-09-091-1/+14
|\ | | | | | | | | | | Enable eager checks for memory sanitizer Fixes #99179
| * Enable eager checks for memory sanitizer52252252022-08-141-1/+14
| |
* | llvm-wrapper: adapt for LLVM API changesKrasimir Georgiev2022-09-071-1/+7
| | | | | | | | | | | | | | | | | | No functional changes intended. Adapts PassWrapper for two recent LLVM API changes: * https://github.com/llvm/llvm-project/commit/e7bac3b9fa739f8d167a390a547068aad1d424a7 * https://github.com/llvm/llvm-project/commit/93600eb50ceeec83c488ded24fa0fd25f997fec6 * https://github.com/llvm/llvm-project/commit/5e38b2a456df6e263a509af60a731cec57310498
* | Auto merge of #98100 - bjorn3:use_object_for_bitcode_reading, r=wesleywiserbors2022-08-301-13/+0
|\ \ | | | | | | | | | | | | | | | Use object instead of LLVM for reading bitcode from rlibs Together with changes I plan to make as part of https://github.com/rust-lang/rust/pull/97485 this will allow entirely removing usage of LLVM's archive reader and thus allow removing `archive_ro.rs` and `ArchiveWrapper.cpp`.
| * | Use object instead of LLVM for reading bitcode from rlibsbjorn32022-07-251-13/+0
| | |
* | | llvm-wrapper: use new pass manager for thin lto with LLVM version 15Krasimir Georgiev2022-08-171-2/+23
| | | | | | | | | | | | | | | | | | | | | No functional changes intended. LLVM commit https://github.com/llvm/llvm-project/commit/633f5663c37a670e28040cadd938200abd854483 removed `createWriteThinLTOBitcodePass`. This adapts PassWrapper similarly to the example mentioned upstream: https://github.com/llvm/llvm-project/commit/633f5663c37a670e28040cadd938200abd854483.
* | | Rollup merge of #100460 - cuviper:drop-llvm-12, r=nagisaMatthias Krüger2022-08-163-63/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the minimum external LLVM to 13 With this change, we'll have stable support for LLVM 13 through 15 (pending release). For reference, the previous increase to LLVM 12 was #90175. r? `@nagisa`
| * | | Update the minimum external LLVM to 13Josh Stone2022-08-143-63/+1
| | |/ | |/|
* | | Rollup merge of #100384 - ridwanabdillahi:instr_profile_output, r=wesleywiserMatthias Krüger2022-08-161-2/+6
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for generating unique profraw files by default when using `-C instrument-coverage` Currently, enabling the rustc flag `-C instrument-coverage` instruments the given crate and by default uses the naming scheme `default.profraw` for any instrumented profile files generated during the execution of a binary linked against this crate. This leads to multiple binaries being executed overwriting one another and causing only the last executable run to contain actual coverage results. This can be overridden by manually setting the environment variable `LLVM_PROFILE_FILE` to use a unique naming scheme. This PR adds a change to add support for a reasonable default for rustc to use when enabling coverage instrumentation similar to how the Rust compiler treats generating these same `profraw` files when PGO is enabled. The new naming scheme is set to `default_%m_%p.profraw` to ensure the uniqueness of each file being generated using [LLVMs special pattern strings](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#running-the-instrumented-program). Today the compiler sets the default for PGO `profraw` files to `default_%m.profraw` to ensure a unique file for each run. The same can be done for the instrumented profile files generated via the `-C instrument-coverage` flag as well which LLVM has API support for. Linked Issue: https://github.com/rust-lang/rust/issues/100381 r? `@wesleywiser`
| * | | Add support for generating unique *.profraw files by default when using the ↵ridwanabdillahi2022-08-111-2/+6
| |/ / | | | | | | | | | | | | | | | `-C instrument-coverage` flag. Respond to PR comments.
* | | debuginfo: Change C++-like encoding for enums.Michael Woerister2022-08-121-0/+24
|/ / | | | | | | | | The updated encoding should be able to handle niche layouts where more than one variant has fields.
* | RustWrapper: update for TypedPointerType in LLVMAugie Fackler2022-08-041-1/+6
| | | | | | | | This is a result of https://reviews.llvm.org/D130592.
* | Also gate AllocatedPointer and AllocAlign definitions by LLVM_VERSION_GEest312022-07-301-0/+2
| | | | | | | | | | | | | | | | | | | | Fixes a warning: warning: llvm-wrapper/RustWrapper.cpp:159:11: warning: enumeration values 'AllocatedPointer' and 'AllocAlign' not handled in switch [-Wswitch] warning: switch (Kind) { warning: ^ Which was fall out from 130a1df71ea73ab9d66d3cb8fc9cdb43155d514b.
* | Add elementtype attributes for llvm.arm.ldrex/strex intrinsicsNikita Popov2022-07-271-0/+22
| | | | | | | | | | These intrinsics (and a few more, but there are the only ones exposed by stdarch) require an elementtype attribute in LLVM 15.
* | Rollup merge of #99759 - bjorn3:remove_llvm_dead_code, r=nikicYuki Okushi2022-07-272-54/+0
|\ \ | | | | | | | | | | | | | | | Remove dead code from cg_llvm Found while working on https://github.com/rust-lang/rust/pull/97485
| * | Remove dead code from cg_llvmbjorn32022-07-262-54/+0
| |/
* | codegen: use new {re,de,}allocator annotations in llvmAugie Fackler2022-07-262-0/+72
|/ | | | | | | | | | | | | | | | | | | | | | | This obviates the patch that teaches LLVM internals about _rust_{re,de}alloc functions by putting annotations directly in the IR for the optimizer. The sole test change is required to anchor FileCheck to the body of the `box_uninitialized` method, so it doesn't see the `allocalign` on `__rust_alloc` and get mad about the string `alloca` showing up. Since I was there anyway, I added some checks on the attributes to prove the right attributes got set. While we're here, we also emit allocator attributes on __rust_alloc_zeroed. This should allow LLVM to perform more optimizations for zeroed blocks, and probably fixes #90032. [This comment](https://github.com/rust-lang/rust/issues/24194#issuecomment-308791157) mentions "weird UB-like behaviour with bitvec iterators in rustc_data_structures" so we may need to back this change out if things go wrong. The new test cases require LLVM 15, so we copy them into LLVM 14-supporting versions, which we can delete when we drop LLVM 14.
* Auto merge of #98208 - ivanloz:master, r=nagisabors2022-07-232-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for LLVM ShadowCallStack. LLVMs ShadowCallStack provides backward edge control flow integrity protection by using a separate shadow stack to store and retrieve a function's return address. LLVM currently only supports this for AArch64 targets. The x18 register is used to hold the pointer to the shadow stack, and therefore this only works on ABIs which reserve x18. Further details are available in the [LLVM ShadowCallStack](https://clang.llvm.org/docs/ShadowCallStack.html) docs. # Usage `-Zsanitizer=shadow-call-stack` # Comments/Caveats * Currently only enabled for the aarch64-linux-android target * Requires the platform to define a runtime to initialize the shadow stack, see the [LLVM docs](https://clang.llvm.org/docs/ShadowCallStack.html) for more detail.
| * Add ShadowCallStack SupportIvan Lozano2022-07-202-0/+3
| | | | | | | | Adds support for the LLVM ShadowCallStack sanitizer.
* | Auto merge of #98162 - nextsilicon:support_lto_embed_bitcode, r=davidtwcobors2022-07-211-2/+7
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | Allow to disable thinLTO buffer to support lto-embed-bitcode lld feature Hello This change is to fix issue (https://github.com/rust-lang/rust/issues/84395) in which passing "-lto-embed-bitcode=optimized" to lld when linking rust code via linker-plugin-lto doesn't produce the expected result. Instead of emitting a single unified module into a llvmbc section of the linked elf, it emits multiple submodules. This is caused because rustc emits the BC modules after running llvm `createWriteThinLTOBitcodePass` pass. Which in turn triggers a thinLTO linkage and causes the said issue. This patch allows via compiler flag (-Cemit-thin-lto=<bool>) to select between running `createWriteThinLTOBitcodePass` and `createBitcodeWriterPass`. Note this pattern of selecting between those 2 passes is common inside of LLVM code. The default is to match the old behavior.
| * rustc: add ability to output regular LTO bitcode modulesZiv Dunkelman2022-07-141-2/+7
| | | | | | | | | | | | | | | | | | | | | | Adding the option to control from rustc CLI if the resulted ".o" bitcode module files are with thinLTO info or regular LTO info. Allows using "-lto-embed-bitcode=optimized" during linkage correctly. Signed-off-by: Ziv Dunkelman <ziv.dunkelman@nextsilicon.com>
* | Rollup merge of #98998 - ↵Dylan DPC2022-07-182-0/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | workingjubilee:naked-means-no-clothes-enforcement-technology, r=Amanieu Remove branch target prologues from `#[naked] fn` This patch hacks around rust-lang/rust#98768 for now via injecting appropriate attributes into the LLVMIR we emit for naked functions. I intend to pursue this upstream so that these attributes can be removed in general, but it's slow going wading through C++ for me.
| * | Stop emitting CET prologues for naked functionsJubilee Young2022-07-062-0/+3
| | | | | | | | | | | | We can apply nocf_check as a hack for now.
* | | Auto merge of #95685 - oxidecomputer:restore-static-dwarf, r=pnkfelixbors2022-07-161-2/+2
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "Work around invalid DWARF bugs for fat LTO" Since September, the toolchain has not been generating reliable DWARF information for static variables when LTO is on. This has affected projects in the embedded space where the use of LTO is typical. In our case, it has kept us from bumping past the 2021-09-22 nightly toolchain lest our debugger break. This has been a pretty dramatic regression for people using debuggers and static variables. See #90357 for more info and a repro case. This commit is a mechanical revert of d5de680e20def848751cb3c11e1182408112b1d3 from PR #89041, which caused the issue. (Note on that PR that the commit's author has requested it be reverted.) I have locally verified that this fixes #90357 by restoring the functionality of both the repro case I posted on that bug, and debugger behavior on real programs. There do not appear to be test cases for this in the toolchain; if I've missed them, point me at 'em and I'll update them.
| * | Revert "Work around invalid DWARF bugs for fat LTO"Cliff L. Biffle2022-04-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since September, the toolchain has not been generating reliable DWARF information for static variables when LTO is on. This has affected projects in the embedded space where the use of LTO is typical. In our case, it has kept us from bumping past the 2021-09-22 nightly toolchain lest our debugger break. This has been a pretty dramatic regression for people using debuggers and static variables. See #90357 for more info and a repro case. This commit is a mechanical revert of d5de680e20def848751cb3c11e1182408112b1d3 from PR #89041, which caused the issue. (Note on that PR that the commit's author has requested it be reverted.) I have locally verified that this fixes #90357 by restoring the functionality of both the repro case I posted on that bug, and debugger behavior on real programs. There do not appear to be test cases for this in the toolchain; if I've missed them, point me at 'em and I'll update them.
* | | llvm-wrapper: adapt for LLVM API changeKrasimir Georgiev2022-07-121-0/+6
| |/ |/|
* | llvm-wrapper: adapt for LLVMConstExtractValue removalKrasimir Georgiev2022-06-301-0/+8
| |
* | llvm-wrapper: adapt for an LLVM API changeKrasimir Georgiev2022-06-281-0/+2
| | | | | | | | | | | | This adapts llvm-wrapper for https://github.com/llvm/llvm-project/commit/dacfa24f75c328ae30b710ecadaa18e4ba10cdc6, which removed ASanGlobalsMetadataAnalysis.
* | Add metadata generation for vtables when using VFEflip19952022-06-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the typeid and `vcall_visibility` metadata to vtables when the -Cvirtual-function-elimination flag is set. The typeid is generated in the same way as for the `llvm.type.checked.load` intrinsic from the trait_ref. The offset that is added to the typeid is always 0. This is because LLVM assumes that vtables are constructed according to the definition in the Itanium ABI. This includes an "address point" of the vtable. In C++ this is the offset in the vtable where information for RTTI is placed. Since there is no RTTI information in Rust's vtables, this "address point" is always 0. This "address point" in combination with the offset passed to the `llvm.type.checked.load` intrinsic determines the final function that should be loaded from the vtable in the `WholeProgramDevirtualization` pass in LLVM. That's why the `llvm.type.checked.load` intrinsics are generated with the typeid of the trait, rather than with that of the function that is called. This matches what `clang` does for C++. The vcall_visibility metadata depends on three factors: 1. LTO level: Currently this is always fat LTO, because LLVM only supports this optimization with fat LTO. 2. Visibility of the trait: If the trait is publicly visible, VFE can only act on its vtables after linking. 3. Number of CGUs: if there is more than one CGU, also vtables with restricted visibility could be seen outside of the CGU, so VFE can only act on them after linking. To reflect this, there are three visibility levels: Public, LinkageUnit, and TranslationUnit.
* | Add LLVM module flags required for the VFE optflip19952022-06-141-0/+5
| | | | | | | | | | | | To apply the optimization the `Virtual Function Elim` module flag has to be set. To apply this optimization post-link the `LTOPostLink` module flag has to be set.
* | RustWrapper: adapt to APInt API changes in LLVM 15Augie Fackler2022-06-071-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | In https://reviews.llvm.org/D125556 upstream changed sext() and zext() to allow some no-op cases, which previously required use of the *OrSelf() methods, which I assume is what was going on here. The *OrSelf() methods got removed in https://reviews.llvm.org/D125559 after two weeks of deprecation because they came with some bonus (probably-undesired) behavior. Since the behavior of sext() and zext() changed slightly, I kept the old *OrSelf() calls in LLVM 14 and earlier, and only use the new version in LLVM 15. r? @nikic
* | RustWrapper: explicitly don't handle DXILPointerTyIDAugie Fackler2022-04-281-0/+5
| | | | | | | | | | | | | | This new enum entry was introduced in https://reviews.llvm.org/D122268, and if I'm reading correctly there's no case where we'd ever encounter it in our uses of LLVM. To preserve the ability to compile this file with -Werror -Wswitch we add an explicit case for this entry.
View Lorry Controller Status