| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fix the sanitizer_scs_attr_check.rs test
The test is failing when targeting aarch64 Android. The intent appears to have been to look for a function attributes comment (or the absence of one) on the line preceding the function declaration. But this isn't quite possible with FileCheck and the test as written was looking for a line with `no_scs` after a line with `scs`, which doesn't appear in the output. Instead, match on the function attributes comment on the line following the demangled function name comment.
|
|
Do the `calloc` optimization for `Option<bool>`
Inspired by <https://old.reddit.com/r/rust/comments/xtiqj8/why_is_this_functional_version_faster_than_my_for/iqqy37b/>.
|
|
|
|
The test is failing when targeting aarch64 Android. The intent appears
to have been to look for a function attributes comment (or the absence
of one) on the line preceding the function declaration. But this isn't
quite possible with FileCheck and the test as written was looking for a
line with `no_scs` after a line with `scs`, which doesn't appear in the
output. Instead, match on the function attributes comment on the line
following the demangled function name comment.
|
|
Enable inline stack probes on X86 with LLVM 16
The known problems with x86 inline-asm stack probes have been solved on LLVM main (16), so this flips the switch. Anyone using bleeding-edge LLVM with rustc can start testing this, as I have done locally. We'll get more direct rust-ci when LLVM 16 branches and we start our upgrade, and we can always patch or disable it then if we find new problems.
The previous attempt was #77885, reverted in #84708.
|
|
Inspired by <https://old.reddit.com/r/rust/comments/xtiqj8/why_is_this_functional_version_faster_than_my_for/iqqy37b/>.
|
|
Tell LLVM that `partition_point` returns a valid fencepost
This was already done for a successful `binary_search`, but this way `partition_point` can get similar optimizations.
Demonstration that nightly can't do this optimization today, and leaves in the panicking path: <https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=e1074cd2faf5f68e49cffd728ded243a>
r? `@thomcc`
|
|
Declare `main` as visibility hidden on targets that default to hidden.
On targets with `default_hidden_visibility` set, which is currrently just WebAssembly, declare the generated `main` function with visibility hidden. This makes it consistent with clang's WebAssembly target, where `main` is just a user function that gets the same visibility as any other user function, which is hidden on WebAssembly unless explicitly overridden.
This will help simplify use cases which in the future may want to automatically wasm-export all visibility-"default" symbols. `main` isn't intended to be wasm-exported, and marking it hidden prevents it from being wasm-exported in that scenario.
|
|
This was already done for a successful `binary_search`, but this way `partition_point` can get similar optimizations.
|
|
|
|
|
|
|
|
Optimize `array::IntoIter`
`.into_iter()` on arrays was slower than it needed to be (especially compared to slice iterator) since it uses `Range<usize>`, which needs to handle degenerate ranges like `10..4`.
This PR adds an internal `IndexRange` type that's like `Range<usize>` but with a safety invariant that means it doesn't need to worry about those cases -- it only handles `start <= end` -- and thus can give LLVM more information to optimize better.
I added one simple demonstration of the improvement as a codegen test.
(`vec::IntoIter` uses pointers instead of indexes, so doesn't have this problem, but that only works because its elements are boxed. `array::IntoIter` can't use pointers because that would keep it from being movable.)
|
|
`.into_iter()` on arrays was slower than it needed to be (especially compared to slice iterator) since it uses `Range<usize>`, which needs to handle degenerate ranges like `10..4`.
This PR adds an internal `IndexRange` type that's like `Range<usize>` but with a safety invariant that means it doesn't need to worry about those cases -- it only handles `start <= end` -- and thus can give LLVM more information to optimize better.
I added one simple demonstration of the improvement as a codegen test.
|
|
|
|
pnkfelix:issue-97463-fix-aarch64-call-abi-does-not-zeroext, r=wesleywiser
Aarch64 call abi does not zeroext (and one cannot assume it does so)
Fix #97463
|
|
|
|
|
|
In https://github.com/rust-lang/rust/pull/100537, the relocation model
for UEFI targets was changed from PIC (the default value) to
static. There was some dicussion of this change here:
https://github.com/rust-lang/rust/pull/100537#discussion_r952363012
It turns out that this can cause compilation to fail as described in
https://github.com/rust-lang/rust/issues/101377, so switch back to PIC.
Fixes https://github.com/rust-lang/rust/issues/101377
|
|
Add a test to make that the failure condition for this pattern is
optimized away.
Fixes #98294.
|
|
Fix a bunch of typo
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
|
|
rustc_target: Add some more target spec sanity checking
|
|
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
|
|
This has been fixed by the LLVM 15 upgrade, add a codegen test.
Fixes #85872.
|
|
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
|
Add MaybeUninit memset test
Closes #96274
|
|
Add pointer masking convenience functions
This PR adds the following public API:
```rust
impl<T: ?Sized> *const T {
fn mask(self, mask: usize) -> *const T;
}
impl<T: ?Sized> *mut T {
fn mask(self, mask: usize) -> *const T;
}
// mod intrinsics
fn mask<T>(ptr: *const T, mask: usize) -> *const T
```
This is equivalent to `ptr.map_addr(|a| a & mask)` but also uses a cool llvm intrinsic.
Proposed in https://github.com/rust-lang/rust/pull/95643#issuecomment-1121562352
cc `@Gankra` `@scottmcm` `@RalfJung`
r? rust-lang/libs-api
|
|
|
|
Make forward compatibility lint deprecated_cfg_attr_crate_type_name deny by default
Turns the forward compatibility lint added by #83744 to deprecate `cfg_attr` usage with `#![crate_type]` and `#![crate_name]` attributes into deny by default. Copying the example from #83744:
```Rust
#![crate_type = "lib"] // remains working
#![cfg_attr(foo, crate_type = "bin")] // will stop working
```
Over 8 months have passed since #83744 was merged so I'd say this gives ample time for people to have been warned, so we can make the warning stronger. No usage was found via grep.app except for one, which was in an unmaintained code base that didn't seem to be used in the open source eco system. The crater run conducted in #83744 also didn't show up anything.
cc #91632 - tracking issue for the lint
|
|
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
|
update test for LLVM change
LLVM commit https://github.com/llvm/llvm-project/commit/c2a38887932e3a46aa3bee35f3f5568ac68282f4 updates the PIC level version selection. Updated an affected rust test to work under both the old and new behaviors.
Detected by our experimental rust + llvm @ HEAD bot:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/12829#0182b368-a405-47a2-b3da-9c79cb907bfe/701-709
|
|
|
|
I couldn't find where exactly it's documented, but apperantly pointers to void
type are invalid in llvm - void is only allowed as a return type of functions.
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #97963 (net listen backlog set to negative on Linux.)
- #99935 (Reenable disabled early syntax gates as future-incompatibility lints)
- #100129 (add miri-test-libstd support to libstd)
- #100500 (Ban references to `Self` in trait object substs for projection predicates too.)
- #100636 (Revert "Revert "Allow dynamic linking for iOS/tvOS targets."")
- #100718 ([rustdoc] Fix item info display)
- #100769 (Suggest adding a reference to a trait assoc item)
- #100777 (elaborate how revisions work with FileCheck stuff in src/test/codegen)
- #100796 (Refactor: remove unnecessary string searchings)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add LLVM15-specific codegen test for `try`/`?`s that now optimize away
These still generated a bunch of code back in Rust 1.63 (<https://rust.godbolt.org/z/z31P8h6rz>), but with LLVM 15 merged they no longer do 🎉
|
|
|
|
extension operation depending on target architecture.
|
|
LLVM commit https://github.com/llvm/llvm-project/commit/c2a38887932e3a46aa3bee35f3f5568ac68282f4
updates the PIC level version selection. This updates the rust tests to
work under both the old and new behaviors.
Detected by our experimental rust + llvm @ HEAD bot:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/12829#0182b368-a405-47a2-b3da-9c79cb907bfe/701-709
|
|
These still generated a bunch of code back in Rust 1.63 (<https://rust.godbolt.org/z/z31P8h6rz>), but with LLVM 15 merged they no longer do :tada:
|
|
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`
|
|
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`
|
|
|
|
|
|
`-C instrument-coverage` flag.
Respond to PR comments.
|
|
Reoptimize layout array
This way it's one check instead of two, so hopefully (cc #99117) it'll be simpler for rustc perf too 🤞
Quick demonstration:
```rust
pub fn demo(n: usize) -> Option<Layout> {
Layout::array::<i32>(n).ok()
}
```
Nightly: <https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=e97bf33508aa03f38968101cdeb5322d>
```nasm
mov rax, rdi
mov ecx, 4
mul rcx
seto cl
movabs rdx, 9223372036854775805
xor esi, esi
cmp rax, rdx
setb sil
shl rsi, 2
xor edx, edx
test cl, cl
cmove rdx, rsi
ret
```
This PR (note no `mul`, in addition to being much shorter):
```nasm
xor edx, edx
lea rax, [4*rcx]
shr rcx, 61
sete dl
shl rdx, 2
ret
```
This is built atop `@CAD97` 's #99136; the new changes are cb8aba66ef6a0e17f08a0574e4820653e31b45a0.
I added a bunch more tests for `Layout::from_size_align` and `Layout::array` too.
|
|
Enable function merging when opt is for size
It is, of course, natural to want to merge aliasing functions when
optimizing for code size, since that can eliminate several bytes.
And an exhaustive match helps make the code less brittle.
Closes #98215.
|
|
It is, of course, natural to want to merge aliasing functions when
optimizing for code size, since that can eliminate several bytes.
And an exhaustive match helps make the code less brittle.
|
