Sync rustc_codegen_cranelift
The highlights this time are improved simd and inline asm support, `is_x86_feature_detected!()` returning the actual cpu features when inline asm support is enabled and a couple of bug fixes.
r? ```@ghost```
```@rustbot``` label +A-codegen +A-cranelift +T-compiler +subtree-sync
Fix suggestion span involving wrongly placed generic arg on variant
Fixes#116473
The span computation was wrong. It went from the end of the variant to the end of the (wrongly placed) args. However, the variant lived in a different expansion and this resulted in a nonsensical span that overlaps with another and thereby leads to the ICE.
In the fix I've changed span computation to not be based on the location of the variant, but purely on the location of the args. I simply extend the start of the args span 2 positions to the left and that includes the `::` and that's all we need apparently.
This approach produces a correct span regardless of which macro/expansion the args reside in and where the variant is.
improve the suggestion of `generic_bound_failure`
- Fixes#115375
- suggest the bound in the correct scope: trait or impl header vs assoc item. See `tests/ui/suggestions/lifetimes/type-param-bound-scope.rs`
- don't suggest a lifetime name that conflicts with the other late-bound regions of the function:
```rust
type Inv<'a> = *mut &'a ();
fn check_bound<'a, T: 'a>(_: T, _: Inv<'a>) {}
fn test<'a, T>(_: &'a str, t: T, lt: Inv<'_>) { // suggests a new name `'a`
check_bound(t, lt); //~ ERROR
}
```
When the variant and the (wrongly placed) args are at separate
source locations such as being in different macos or one in a macro and
the other somwhere outside of it, the arg spans we computed spanned
the entire distance between such locations and were hence invalid.
.
Generalize small dominators optimization
* Use small dominators optimization from 640ede7b0a more generally.
* Merge `DefLocation` and `LocationExtended` since they serve the same purpose.
Always preserve DebugInfo in DeadStoreElimination.
This is a version of #106852 that does not check the current crate's debuginfo flag, and always attempts to preserve debuginfo.
I haven't figured out how to handle mixing debuginfo levels for std, the one for the test, and the one for the CI target just right to merge #106852, so this can at least fix the debuginfo issue.
Fixes https://github.com/rust-lang/rust/issues/103655
Fix to register analysis passes with -Zllvm-plugins at link-time
This PR fixes an unexpected behavior of the `-Zllvm-plugins` flag. It allows to run an out-of-tree pass as part of LTO.
However, analysis passes are registered before the plugin is loaded. As a result an analysis pass, which is passed as a plugin, is not registered. This causes the LLVM PassManager to fail when the analysis pass is queried from a transformation pass [(here)](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/PassManager.h#L776).
This fix mimics the bahavior in [LLVM LTOBackend.cpp](https://github.com/llvm/llvm-project/blob/main/llvm/lib/LTO/LTOBackend.cpp#L273) by loading the plugin before the analysis passes are registered.
Tested with rustc 1.60 and 1.65 and LLVM-13.0.1.
remove Key impls for types that involve an AllocId
I don't understand how but somehow that leads to issues like https://github.com/rust-lang/rust/issues/83085? Anyway removing unused impls doesn't seem like a bad idea. The concerning part is that of course nothing will stop us from having such impls again in the future, alongside re-introducing bugs like #83085.
r? `@oli-obk`
