| Age | Commit message (Collapse) | Author | Lines |
|---|
|
LLVMRustBuildCleanupPad -> LLVMBuildCleanupPad
LLVMRustBuildCleanupRet -> LLVMBuildCleanupRet
LLVMRustBuildCatchPad -> LLVMBuildCatchPad
LLVMRustBuildCatchRet -> LLVMBuildCatchRet
LLVMRustBuildCatchSwitch -> LLVMBuildCatchSwitch
|
|
LLVMRustMetadataTypeInContext with LLVMMetadataTypeInContext
|
|
|
|
LLVMValueRef, some that accept LLVMMetadataRef, and replacing one with another not always possible without explicit convertion
|
|
|
|
|
|
llvm-wrapper: adapt for LLVM API change
No functional changes intended.
The LLVM commit https://github.com/llvm/llvm-project/commit/e6b02214c68df2c9f826e02310c9352ac652e456 added `TargetExtTyID` to the `TypeID` enum. This adapts `RustWrapper` accordingly.
|
|
LLVM upstream has deprecated llvm::makeArrayRef and will remove it.
|
|
No functional changes intended.
The LLVM commit https://github.com/llvm/llvm-project/commit/e6b02214c68df2c9f826e02310c9352ac652e456 added `TargetExtTyID` to the `TypeID` enum. This adapts `RustWrapper` accordingly.
|
|
This is a follow-up of
https://github.com/rust-lang/rust/commit/75aec4703dea7ef8e13924ccfa3a3d2e8c5c7cff.
There, I updated the wrapper to only include llvm/ADT/Optional.h for
LLVM version below 16. But I missed updating some of the None references.
Found by our experimental rust + llvm at HEAD bot:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/15587#0185006b-e0af-49e5-8b06-280ed125ff0d/200-539
|
|
Add LLVM KCFI support to the Rust compiler
This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
|
|
This commit adds LLVM Kernel Control Flow Integrity (KCFI) support to
the Rust compiler. It initially provides forward-edge control flow
protection for operating systems kernels for Rust-compiled code only by
aggregating function pointers in groups identified by their return and
parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by identifying C char and integer type uses at the
time types are encoded (see Type metadata in the design document in the
tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
llvm-wrapper: adapt for an LLVM API change
Adapts llvm-wrapper for https://github.com/llvm/llvm-project/commit/8c7c20f033c7036a8bf231ca6f9e02172cb581f0.
No functional changes intended.
Found via our experimental rust + llvm @ HEAD bot: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/15404#0184d95d-5a68-4db6-ad32-51ddbc3ab543/202-571
|
|
|
|
This allows it to be used by other codegen backends
|
|
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
|
|
|
|
|
|
|
|
|
|
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``
|
|
|
|
|
|
which verifies that a constant bit width is within 64 bits or fails.
|
|
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`
|
|
|
|
The updated encoding should be able to handle niche layouts where
more than one variant has fields.
|
|
This is a result of https://reviews.llvm.org/D130592.
|
|
These intrinsics (and a few more, but there are the only ones
exposed by stdarch) require an elementtype attribute in LLVM 15.
|
|
Remove dead code from cg_llvm
Found while working on https://github.com/rust-lang/rust/pull/97485
|
|
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.
|
|
|
|
Adds support for the LLVM ShadowCallStack sanitizer.
|
|
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.
|
|
|
|
We can apply nocf_check as a hack for now.
|
|
|
|
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.
|
|
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.
|
|
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
|
|
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.
|
|
|
|
|
|
This is required after LLVM change 3c4410dfcaaf (aka
https://reviews.llvm.org/D121168) did some includes cleanup.
|
|
|
|
Remove LLVM attribute removal
This was necessary before, because `declare_raw_fn` would always apply
the default optimization attributes to every declared function.
Then `attributes::from_fn_attrs` would have to remove the default
attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build.
(see [`src/test/codegen/optimize-attr-1.rs`](https://github.com/rust-lang/rust/blob/03a8cc7df1d65554a4d40825b0490c93ac0f0236/src/test/codegen/optimize-attr-1.rs#L33))
However, every relevant callsite of `declare_raw_fn` (i.e. where we
actually generate code for the function, and not e.g. a call to an
intrinsic, where optimization attributes don't [?] matter)
calls `from_fn_attrs`, so we can remove the attribute setting
from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct
attributes all at once.
r? `@ghost` (blocked on #94221)
`@rustbot` label S-blocked
|
|
This was necessary before, because `declare_raw_fn` would always apply
the default optimization attributes to every declared function,
and then `attributes::from_fn_attrs` would have to remove the default
attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build.
However, every relevant callsite of `declare_raw_fn` (i.e. where we
actually generate code for the function, and not e.g. a call to an
intrinsic, where optimization attributes don't [?] matter)
calls `from_fn_attrs`, so we can simply remove the attribute setting
from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct
attributes all at once.
|
|
This reverts commit 4f49627c6fe2a32d1fed6310466bb0e1c535c0c0, reversing
changes made to 028c6f1454787c068ff5117e9000a1de4fd98374.
|
|
|
|
|
