| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This is going to be required for binding a number of AVX-512 intrinsics
in the `stdsimd` repository, and this intrinsic is the same as
`simd_select` except that it takes a bitmask as the first argument
instead of a SIMD vector. This bitmask is then transmuted into a `<NN x
i8>` argument, depending on how many bits it is.
cc rust-lang-nursery/stdsimd#310
|
|
This was intended to land way back in 1.24, but it was backed out due to
breakage which has long since been fixed. An unstable `#[unwind]`
attribute can be used to tweak the behavior here, but this is currently
simply switching rustc's internal default to abort-by-default if an
`extern` function panics, making our codegen sound primarily (as
currently you can produce UB with safe code)
Closes #52652
|
|
|
|
Add template parameter debuginfo to generic types
This changes debuginfo generation to add template parameters to
generic types. With this change the DWARF now has
DW_TAG_template_type_param for types, not just for functions, like:
<2><40d>: Abbrev Number: 6 (DW_TAG_structure_type)
<40e> DW_AT_name : (indirect string, offset: 0x375): Generic<i32>
<412> DW_AT_byte_size : 4
<413> DW_AT_alignment : 4
...
<3><41f>: Abbrev Number: 8 (DW_TAG_template_type_param)
<420> DW_AT_type : <0x42a>
<424> DW_AT_name : (indirect string, offset: 0xa65e): T
Closes #9224
|
|
If the Rust LLVM fork is used, enable the -mergefunc-use-aliases
flag, which will create aliases for merged functions, rather than
inserting a call from one to the other.
A number of codegen tests needed to be adjusted, because functions
that previously fell below the thunk limit are now being merged.
Merging is prevented either using -C no-prepopulate-passes, or by
making the functions non-identical.
I expect that this is going to break something, somewhere, because
it isn't able to deal with aliases properly, but we won't find out
until we try :)
This fixes #52651.
|
|
This changes debuginfo generation to add template parameters to
generic types. With this change the DWARF now has
DW_TAG_template_type_param for types, not just for functions, like:
<2><40d>: Abbrev Number: 6 (DW_TAG_structure_type)
<40e> DW_AT_name : (indirect string, offset: 0x375): Generic<i32>
<412> DW_AT_byte_size : 4
<413> DW_AT_alignment : 4
...
<3><41f>: Abbrev Number: 8 (DW_TAG_template_type_param)
<420> DW_AT_type : <0x42a>
<424> DW_AT_name : (indirect string, offset: 0xa65e): T
Closes #9224
|
|
rustc_codegen_llvm: don't overalign loads of pair operands.
Counterpart to #56300, but for loads instead of stores.
|
|
|
|
The alignment for the second element of a scalar pair is not the
same as for the first element. Make sure it is computed correctly
based on the element size.
|
|
As reported in https://github.com/rust-lang/rust/pull/54668#issuecomment-440186476
|
|
more platforms
|
|
same ABI
This is supposed to fix the performence regression of using MaybeUninit in
https://github.com/rust-lang/rust/pull/54668
|
|
Fix emission of niche-filling discriminant values
Bug #55606 points out a regression introduced by #54004; namely that
an assertion can erroneously fire when a niche-filling discriminant
value is emitted.
This fixes the bug by removing the assertion, and furthermore by
arranging for the discriminant value to be masked according to the
size of the niche. This makes handling the discriminant a bit simpler
for debuggers.
The test case is from Jonathan Turner.
Closes #55606
|
|
Bug #55606 points out a regression introduced by #54004; namely that
an assertion can erroneously fire when a niche-filling discriminant
value is emitted.
This fixes the bug by removing the assertion, and furthermore by
arranging for the discriminant value to be masked according to the
size of the niche. This makes handling the discriminant a bit simpler
for debuggers.
The test case is from Jonathan Turner.
Closes #55606
|
|
If LLVM 7 is used, generate memcpy/memmove with differing
src/dst alignment. I've added new FFI functions to construct
these through the builder API, which is more convenient than
dealing with differing intrinsic signatures depending on the
LLVM version.
|
|
Rename the previous enum debug info test, and add more tests to cover
c-like enums and tagged (ordinary) enums.
|
|
Update the new enum-debug to ensure that field "D" does not have a
discrimnant.
|
|
The DWARF generated for Rust enums was always somewhat unusual.
Rather than using DWARF constructs directly, it would emit magic field
names like "RUST$ENCODED$ENUM$0$Name" and "RUST$ENUM$DISR". Since
PR #45225, though, even this has not worked -- the ad hoc scheme was
not updated to handle the wider variety of niche-filling layout
optimizations now available.
This patch changes the generated DWARF to use the standard tags meant
for this purpose; namely, DW_TAG_variant and DW_TAG_variant_part.
The patch to implement this went in to LLVM 7. In order to work with
older versions of LLVM, and because LLVM doesn't do anything here for
PDB, the existing code is kept as a fallback mode.
Support for this DWARF is in the Rust lldb and in gdb 8.2.
Closes #32920
Closes #32924
Closes #52762
Closes #53153
|
|
rustc: Tweak filenames encoded into metadata
This commit is a fix for #54408 where on nightly right now whenever
generics are inlined the path name listed for the inlined function's
debuginfo is a relative path to the cwd, which surely doesn't exist!
Previously on beta/stable the debuginfo mentioned an absolute path which
still didn't exist, but more predictably didn't exist.
The change between stable/nightly is that nightly is now compiled with
`--remap-path-prefix` to give a deterministic prefix to all
rustc-generated paths in debuginfo. By using `--remap-path-prefix` the
previous logic would recognize that the cwd was remapped, causing the
original relative path name of the standard library to get emitted. If
`--remap-path-prefix` *wasn't* passed in then the logic would create an
absolute path name and then create a new source file entry.
The fix in this commit is to apply the "recreate the source file entry
with an absolute path" logic a bit more aggresively. If the source
file's name was remapped then we don't touch it, but otherwise we always
take the working dir (which may have been remapped) and then join it to
the file to ensure that we process all relative file names as well.
The end result is that the standard library should have an absolute path
for all file names in debuginfo (using our `--remap-path-prefix`
argument) as it does on stable after this patch.
Closes #54408
|
|
Disable the PLT where possible to improve performance
for indirect calls into shared libraries.
This optimization is enabled by default where possible.
- Add the `NonLazyBind` attribute to `rustllvm`:
This attribute informs LLVM to skip PLT calls in codegen.
- Disable PLT unconditionally:
Apply the `NonLazyBind` attribute on every function.
- Only enable no-plt when full relro is enabled:
Ensures we only enable it when we have linker support.
- Add `-Z plt` as a compiler option
|
|
oli-obk:mögen_konstante_funktionen_doch_bitte_endlich_stabil_sein, r=Centril
Stabilize `min_const_fn`
tracking issue: #53555
r? @Centril
|
|
This commit updates the compiler to allow the `#[no_mangle]` (and
`#[export_name]` attributes) to be located anywhere within a crate.
These attributes are unconditionally processed, causing the compiler to
always generate an exported symbol with the appropriate name.
After some discussion on #54135 it was found that not a great reason
this hasn't been allowed already, and it seems to match the behavior
that many expect! Previously the compiler would only export a
`#[no_mangle]` symbol if it were *publicly reachable*, meaning that it
itself is `pub` and it's otherwise publicly reachable from the root of
the crate. This new definition is that `#[no_mangle]` *is always
reachable*, no matter where it is in a crate or whether it has `pub` or
not.
This should make it much easier to declare an exported symbol with a
known and unique name, even when it's an internal implementation detail
of the crate itself. Note that these symbols will persist beyond LTO as
well, always making their way to the linker.
Along the way this commit removes the `private_no_mangle_functions` lint
(also for statics) as there's no longer any need to lint these
situations. Furthermore a good number of tests were updated now that
symbol visibility has been changed.
Closes #54135
|
|
|
|
|
|
Do not put noalias annotations by default
This will be re-enabled sooner or later depending on results of further
investigation.
Fixes #54462
Beta backport is: #54640
r? @nikomatsakis
|
|
This will be re-enabled sooner or later depending on results of further
investigation.
Fixes #54462
|
|
Revert most of MaybeUninit, except for the new API itself
This reverts most of https://github.com/rust-lang/rust/pull/53508/ for perf reasons (first commit reverts that entire PR), except for the new API itself (added back in 2nd commit).
|
|
This reverts commit c6e3d7fa3113aaa64602507f39d4627c427742ff, reversing
changes made to 4591a245c7eec9f70d668982b1383cd2a6854af5.
|
|
ignore {std,fast,vector,this}call on non-x86 windows
MSVC ignores these keywords for C/C++ and uses the standard system
calling convention. Rust should do so as well.
Fixes #54569.
|
|
This commit is a fix for #54408 where on nightly right now whenever
generics are inlined the path name listed for the inlined function's
debuginfo is a relative path to the cwd, which surely doesn't exist!
Previously on beta/stable the debuginfo mentioned an absolute path which
still didn't exist, but more predictably didn't exist.
The change between stable/nightly is that nightly is now compiled with
`--remap-path-prefix` to give a deterministic prefix to all
rustc-generated paths in debuginfo. By using `--remap-path-prefix` the
previous logic would recognize that the cwd was remapped, causing the
original relative path name of the standard library to get emitted. If
`--remap-path-prefix` *wasn't* passed in then the logic would create an
absolute path name and then create a new source file entry.
The fix in this commit is to apply the "recreate the source file entry
with an absolute path" logic a bit more aggresively. If the source
file's name was remapped then we don't touch it, but otherwise we always
take the working dir (which may have been remapped) and then join it to
the file to ensure that we process all relative file names as well.
The end result is that the standard library should have an absolute path
for all file names in debuginfo (using our `--remap-path-prefix`
argument) as it does on stable after this patch.
Closes #54408
|
|
MSVC ignores these keywords for C/C++ and uses the standard system
calling convention. Rust should do so as well.
Fixes #54569.
|
|
Fix #54028
|
|
|
|
|
|
|
|
Change `Rc::inc_{weak,strong}` to better hint optimization to LLVM
As discussed in #13018, `Rc::inc_strong` and `Rc::inc_weak` are changed to allow compositions of `clone` and `drop` to be better optimized. Almost entirely as in [this comment](https://github.com/rust-lang/rust/issues/13018#issuecomment-408642184), except that `abort` on zero is added so that a `drop(t.clone())` does not produce a zero check followed by conditional deallocation.
This is different from #21418 in that it doesn't rely on `assume`, avoiding the prohibitive compilation slowdown.
[Before and after IR](https://gist.github.com/hermord/266e55451b7fe0bb8caa6e35d17c86e1).
|
|
|
|
|
|
|
|
debug_assert to ensure that from_raw_parts is only used properly aligned
This does not help nearly as much as I would hope because everybody uses the distributed libstd which is compiled without debug assertions. For this reason, I am not sure if this is even worth it. OTOH, this would have caught the misalignment fixed by https://github.com/rust-lang/rust/issues/42789 *if* there had been any tests actually using ZSTs with alignment >1 (we have a CI runner which has debug assertions in libstd enabled), and it seems to currently [fail in the rg testsuite](https://ci.appveyor.com/project/rust-lang/rust/build/1.0.8403/job/v7dfdcgn8ay5j6sb). So maybe it is worth it, after all.
I have seen the attribute `#[rustc_inherit_overflow_checks]` in some places, does that make it so that the *caller's* debug status is relevant? Is there a similar attribute for `debug_assert!`? That could even subsume `rustc_inherit_overflow_checks`: Something like `rustc_inherit_debug_flag` could affect *all* places that change the generated code depending on whether we are in debug or release mode. In fact, given that we have to keep around the MIR for generic functions anyway, is there ever a reason *not* to handle the debug flag that way? I guess currently we apply debug flags like `cfg` so this is dropped early during the MIR pipeline?
EDIT: I learned from @eddyb that because of how `debug_assert!` works, this is not realistic. Well, we could still have it for the rustc CI runs and then maybe, eventually, when libstd gets compiled client-side and there is both a debug and a release build... then this will also benefit users.^^
|
|
|
|
of the attribute.
|
|
|
|
|
|
|
|
Make globals with private linkage unnamed. Fixes #50862.
cc @oli-obk @nagisa
|
|
|
|
Use SetLenOnDrop in Vec::truncate()
This avoids a redundant length check in some cases when calling
`Vec::truncate` or `Vec::clear`.
Fixes #51802
Note that the generated code still seems suboptimal. I tested with the following functions:
```rust
#[no_mangle]
pub extern fn foo(x: &mut Vec<u8>) {
x.clear();
}
#[no_mangle]
pub extern fn bar(x: &mut Vec<u8>) {
x.truncate(5);
}
#[no_mangle]
pub extern fn baz(x: &mut Vec<u8>, n: usize) {
x.truncate(n);
}
#[no_mangle]
pub extern fn foo_string(x: &mut Vec<String>) {
x.clear();
}
#[no_mangle]
pub extern fn bar_string(x: &mut Vec<String>) {
x.truncate(5);
}
#[no_mangle]
pub extern fn baz_string(x: &mut Vec<String>, n: usize) {
x.truncate(n);
}
```
<details>
<summary>Old output</summary>
```asm
00000000000460a0 <foo>:
460a0: 48 83 7f 10 00 cmpq $0x0,0x10(%rdi)
460a5: 74 08 je 460af <foo+0xf>
460a7: 48 c7 47 10 00 00 00 movq $0x0,0x10(%rdi)
460ae: 00
460af: c3 retq
00000000000460b0 <bar>:
460b0: 48 83 7f 10 06 cmpq $0x6,0x10(%rdi)
460b5: 72 08 jb 460bf <bar+0xf>
460b7: 48 c7 47 10 05 00 00 movq $0x5,0x10(%rdi)
460be: 00
460bf: c3 retq
00000000000460c0 <baz>:
460c0: 48 39 77 10 cmp %rsi,0x10(%rdi)
460c4: 76 04 jbe 460ca <baz+0xa>
460c6: 48 89 77 10 mov %rsi,0x10(%rdi)
460ca: c3 retq
460cb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
00000000000460d0 <foo_string>:
460d0: 41 57 push %r15
460d2: 41 56 push %r14
460d4: 53 push %rbx
460d5: 48 8b 47 10 mov 0x10(%rdi),%rax
460d9: 48 85 c0 test %rax,%rax
460dc: 74 4a je 46128 <foo_string+0x58>
460de: 49 89 fe mov %rdi,%r14
460e1: 48 8b 0f mov (%rdi),%rcx
460e4: 48 8d 14 40 lea (%rax,%rax,2),%rdx
460e8: 48 8d 58 ff lea -0x1(%rax),%rbx
460ec: 4c 8d 3c d1 lea (%rcx,%rdx,8),%r15
460f0: 49 83 c7 f0 add $0xfffffffffffffff0,%r15
460f4: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
460fb: 00 00 00
460fe: 66 90 xchg %ax,%ax
46100: 49 89 5e 10 mov %rbx,0x10(%r14)
46104: 49 8b 37 mov (%r15),%rsi
46107: 48 85 f6 test %rsi,%rsi
4610a: 74 0e je 4611a <foo_string+0x4a>
4610c: 49 8b 7f f8 mov -0x8(%r15),%rdi
46110: ba 01 00 00 00 mov $0x1,%edx
46115: e8 a6 e9 ff ff callq 44ac0 <__rust_dealloc@plt>
4611a: 48 83 c3 ff add $0xffffffffffffffff,%rbx
4611e: 49 83 c7 e8 add $0xffffffffffffffe8,%r15
46122: 48 83 fb ff cmp $0xffffffffffffffff,%rbx
46126: 75 d8 jne 46100 <foo_string+0x30>
46128: 5b pop %rbx
46129: 41 5e pop %r14
4612b: 41 5f pop %r15
4612d: c3 retq
4612e: 66 90 xchg %ax,%ax
0000000000046130 <bar_string>:
46130: 41 57 push %r15
46132: 41 56 push %r14
46134: 53 push %rbx
46135: 4c 8b 7f 10 mov 0x10(%rdi),%r15
46139: 49 83 ff 06 cmp $0x6,%r15
4613d: 72 49 jb 46188 <bar_string+0x58>
4613f: 49 89 fe mov %rdi,%r14
46142: 48 8b 07 mov (%rdi),%rax
46145: 4b 8d 0c 7f lea (%r15,%r15,2),%rcx
46149: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx
4614d: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx
46151: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
46158: 00 00 00
4615b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
46160: 49 83 c7 ff add $0xffffffffffffffff,%r15
46164: 4d 89 7e 10 mov %r15,0x10(%r14)
46168: 48 8b 33 mov (%rbx),%rsi
4616b: 48 85 f6 test %rsi,%rsi
4616e: 74 0e je 4617e <bar_string+0x4e>
46170: 48 8b 7b f8 mov -0x8(%rbx),%rdi
46174: ba 01 00 00 00 mov $0x1,%edx
46179: e8 42 e9 ff ff callq 44ac0 <__rust_dealloc@plt>
4617e: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx
46182: 49 83 ff 05 cmp $0x5,%r15
46186: 77 d8 ja 46160 <bar_string+0x30>
46188: 5b pop %rbx
46189: 41 5e pop %r14
4618b: 41 5f pop %r15
4618d: c3 retq
4618e: 66 90 xchg %ax,%ax
0000000000046190 <baz_string>:
46190: 41 57 push %r15
46192: 41 56 push %r14
46194: 41 54 push %r12
46196: 53 push %rbx
46197: 50 push %rax
46198: 4c 8b 67 10 mov 0x10(%rdi),%r12
4619c: 49 39 f4 cmp %rsi,%r12
4619f: 76 46 jbe 461e7 <baz_string+0x57>
461a1: 49 89 f6 mov %rsi,%r14
461a4: 49 89 ff mov %rdi,%r15
461a7: 48 8b 07 mov (%rdi),%rax
461aa: 4b 8d 0c 64 lea (%r12,%r12,2),%rcx
461ae: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx
461b2: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx
461b6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
461bd: 00 00 00
461c0: 49 83 c4 ff add $0xffffffffffffffff,%r12
461c4: 4d 89 67 10 mov %r12,0x10(%r15)
461c8: 48 8b 33 mov (%rbx),%rsi
461cb: 48 85 f6 test %rsi,%rsi
461ce: 74 0e je 461de <baz_string+0x4e>
461d0: 48 8b 7b f8 mov -0x8(%rbx),%rdi
461d4: ba 01 00 00 00 mov $0x1,%edx
461d9: e8 e2 e8 ff ff callq 44ac0 <__rust_dealloc@plt>
461de: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx
461e2: 4d 39 f4 cmp %r14,%r12
461e5: 77 d9 ja 461c0 <baz_string+0x30>
461e7: 48 83 c4 08 add $0x8,%rsp
461eb: 5b pop %rbx
461ec: 41 5c pop %r12
461ee: 41 5e pop %r14
461f0: 41 5f pop %r15
461f2: c3 retq
461f3: 90 nop
461f4: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
461fb: 00 00 00
461fe: 66 90 xchg %ax,%ax
```
</details>
<details>
<summary>New output</summary>
```asm
0000000000084d10 <foo>:
84d10: 48 c7 47 10 00 00 00 movq $0x0,0x10(%rdi)
84d17: 00
84d18: c3 retq
84d19: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
0000000000084d20 <bar>:
84d20: 48 8b 47 10 mov 0x10(%rdi),%rax
84d24: 48 83 f8 05 cmp $0x5,%rax
84d28: b9 05 00 00 00 mov $0x5,%ecx
84d2d: 48 0f 42 c8 cmovb %rax,%rcx
84d31: 48 89 4f 10 mov %rcx,0x10(%rdi)
84d35: c3 retq
84d36: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
84d3d: 00 00 00
0000000000084d40 <baz>:
84d40: 48 8b 47 10 mov 0x10(%rdi),%rax
84d44: 48 39 f0 cmp %rsi,%rax
84d47: 48 0f 47 c6 cmova %rsi,%rax
84d4b: 48 89 47 10 mov %rax,0x10(%rdi)
84d4f: c3 retq
0000000000084d50 <foo_string>:
84d50: 41 57 push %r15
84d52: 41 56 push %r14
84d54: 53 push %rbx
84d55: 49 89 fe mov %rdi,%r14
84d58: 4c 8b 7f 10 mov 0x10(%rdi),%r15
84d5c: 4d 85 ff test %r15,%r15
84d5f: 74 2f je 84d90 <foo_string+0x40>
84d61: 49 8b 06 mov (%r14),%rax
84d64: 4b 8d 0c 7f lea (%r15,%r15,2),%rcx
84d68: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx
84d6c: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx
84d70: 48 8b 33 mov (%rbx),%rsi
84d73: 48 85 f6 test %rsi,%rsi
84d76: 74 0e je 84d86 <foo_string+0x36>
84d78: 48 8b 7b f8 mov -0x8(%rbx),%rdi
84d7c: ba 01 00 00 00 mov $0x1,%edx
84d81: e8 1a b1 ff ff callq 7fea0 <__rust_dealloc@plt>
84d86: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx
84d8a: 49 83 c7 ff add $0xffffffffffffffff,%r15
84d8e: 75 e0 jne 84d70 <foo_string+0x20>
84d90: 49 c7 46 10 00 00 00 movq $0x0,0x10(%r14)
84d97: 00
84d98: 5b pop %rbx
84d99: 41 5e pop %r14
84d9b: 41 5f pop %r15
84d9d: c3 retq
84d9e: 66 90 xchg %ax,%ax
0000000000084da0 <bar_string>:
84da0: 41 57 push %r15
84da2: 41 56 push %r14
84da4: 53 push %rbx
84da5: 49 89 fe mov %rdi,%r14
84da8: 4c 8b 7f 10 mov 0x10(%rdi),%r15
84dac: 49 83 ff 06 cmp $0x6,%r15
84db0: 72 44 jb 84df6 <bar_string+0x56>
84db2: 49 8b 06 mov (%r14),%rax
84db5: 4b 8d 0c 7f lea (%r15,%r15,2),%rcx
84db9: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx
84dbd: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx
84dc1: 49 83 c7 fb add $0xfffffffffffffffb,%r15
84dc5: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
84dcc: 00 00 00
84dcf: 90 nop
84dd0: 48 8b 33 mov (%rbx),%rsi
84dd3: 48 85 f6 test %rsi,%rsi
84dd6: 74 0e je 84de6 <bar_string+0x46>
84dd8: 48 8b 7b f8 mov -0x8(%rbx),%rdi
84ddc: ba 01 00 00 00 mov $0x1,%edx
84de1: e8 ba b0 ff ff callq 7fea0 <__rust_dealloc@plt>
84de6: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx
84dea: 49 83 c7 ff add $0xffffffffffffffff,%r15
84dee: 75 e0 jne 84dd0 <bar_string+0x30>
84df0: 41 bf 05 00 00 00 mov $0x5,%r15d
84df6: 4d 89 7e 10 mov %r15,0x10(%r14)
84dfa: 5b pop %rbx
84dfb: 41 5e pop %r14
84dfd: 41 5f pop %r15
84dff: c3 retq
0000000000084e00 <baz_string>:
84e00: 41 57 push %r15
84e02: 41 56 push %r14
84e04: 41 54 push %r12
84e06: 53 push %rbx
84e07: 50 push %rax
84e08: 49 89 ff mov %rdi,%r15
84e0b: 48 8b 47 10 mov 0x10(%rdi),%rax
84e0f: 49 89 c4 mov %rax,%r12
84e12: 49 29 f4 sub %rsi,%r12
84e15: 76 3c jbe 84e53 <baz_string+0x53>
84e17: 49 89 f6 mov %rsi,%r14
84e1a: 49 8b 0f mov (%r15),%rcx
84e1d: 48 8d 04 40 lea (%rax,%rax,2),%rax
84e21: 48 8d 1c c1 lea (%rcx,%rax,8),%rbx
84e25: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx
84e29: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
84e30: 48 8b 33 mov (%rbx),%rsi
84e33: 48 85 f6 test %rsi,%rsi
84e36: 74 0e je 84e46 <baz_string+0x46>
84e38: 48 8b 7b f8 mov -0x8(%rbx),%rdi
84e3c: ba 01 00 00 00 mov $0x1,%edx
84e41: e8 5a b0 ff ff callq 7fea0 <__rust_dealloc@plt>
84e46: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx
84e4a: 49 83 c4 ff add $0xffffffffffffffff,%r12
84e4e: 75 e0 jne 84e30 <baz_string+0x30>
84e50: 4c 89 f0 mov %r14,%rax
84e53: 49 89 47 10 mov %rax,0x10(%r15)
84e57: 48 83 c4 08 add $0x8,%rsp
84e5b: 5b pop %rbx
84e5c: 41 5c pop %r12
84e5e: 41 5e pop %r14
84e60: 41 5f pop %r15
84e62: c3 retq
84e63: 90 nop
84e64: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
84e6b: 00 00 00
84e6e: 66 90 xchg %ax,%ax
```
</details>
For calling `truncate` with non-zero lengths on non-`Drop` types, it seems that a redundant load and comparison gets replaced with an awkward sequence with a conditional move. In the unknown length case, the new code is no longer awkward.
Maybe someone moderately proficient at assembly could tell if this looks like a win or not.
---
This came up when discussing replacing `unsafe { vec.set_len(0) }` with `vec.clear()` in a project where the author was worried about potential performance degradation. It might be worth replacing some unsafe code, even it it's trivial to see that it's actually safe.
|
|
Only run the sparc-abi test on sparc
It is not required for LLVM to have SPARC target support, so it is
necessary to only run this test when LLVM does support SPARC. Sadly, it
isn’t possible to specify exactly this constraint. Instead, we specify
that this test should run on SPARC host only (it surely is sane
assumption to make that compiler running on a SPARC can generate
SPARC, right?)
Since you cannot specify multiple `only-*` to have it run on both 32-bit
and 64-bit SPARC we pick 64-bit SPARC, because it is exactly what is
being tested by this test.
Fixes #52881
|
|
Make sure #47772 does not regress
Mostly to make my life in https://github.com/rust-lang/rust/pull/52206 harder.^^
Or should I just add that test there?
|
