Support removed LLVM intrinsics by invoking its AutoUpgrade mechanism.
Turns out that LLVM sometimes renames platform intrinsics or replaces them with first-class instructions.
For example, signed minimum became `select (icmp SLT, a, b), a, b` where `a` and `b` are vectors.
This is blocking the Servo rustup ([relevant failure](http://build.servo.org/builders/windows-dev/builds/226/steps/compile/logs/stdio)), as they're using a few such intrinsics.
The fix in this PR is to invoke LLVM's own `AutoUpgrade` mechanism to do the replacements.
Add -mrelax-relocations=no hacks to fix musl build
* this is just a start, dunno if it will work, but I'll just push it out to get feedback (my rust is still building 😢)
* I don't know much about rustbuild, so i just added that flag in there. it's a total hack, don't judge me
* I suspect the places in the musl .mk files are sufficient (but we may also need it present when building std), I'm not sure, needs more testing.
core: fix `cargo build` for targets with "max-atomic-width": 0
This crate was failing to compile due to dead_code/unused_imports
warnings. This commits disables these two lints for these targets.
---
r? @alexcrichton
cc @Amanieu is `cfg(target_has_atomic = "8")` the right `cfg` to use? I think that all targets that support some form of atomics will at a minimum support byte level atomics.
FWIW, the only thing that's left in `sync::atomic` for these targets is `Ordering` and the `fence` function.
I cannot figure out how to write a test for this, but I observed
incorrect edges as a result of not using memoized pattern here
(e.g., LateLintCheck -> SizedConstraint).
rustc_trans: don't lose the cross-crate DefId, MIR trans needs it.
We might have been missing out on some issues because MIR trans was never being used cross-crate.
cc @rust-lang/compiler
When we hash the inputs to a MetaData node, we have to hash them in a
consistent order. We achieve this by sorting the stringfied `DefPath`
entries. Also, micro-optimie by cache more results across the saving
process.
The reads will occur naturally as the HIR/MIR is fetched from the
tracked tables, and this winds up adding reads to the hir of foreign
def-ids somehow.
The biggest problem, actually, is krate numbers being removed entirely,
which can lead to array-index-out-of-bounds errors.
cc #35123 -- not a complete fix, since really we ought to "map" the old
crate numbers to the new ones, not just detect changes.
The way we do HIR inlining introduces reads of the "Hir" into the graph,
but this Hir in fact belongs to other crates, so when we try to load
later, we ICE because the Hir nodes in question don't belond to the
crate (and we haven't done inlining yet). This pass rewrites those HIR
nodes to the metadata from which the inlined HIR was loaded.
Switch to MIR-based translation by default.
This patch makes `-Z orbit` default to "on", which means that by default, functions will be translated from Rust to LLVM IR through the upcoming MIR backend, instead of the antiquated AST backend.
This switch is made possible by the recently merged #33622, #33905 and smaller fixes.
If you experience any issues, please file a report for each of them. You can switch to the old backend to work around problems by either setting `RUSTFLAGS="-Zorbit=off"` or by annotating specific functions with `#[rustc_no_mir]` (which requires `#![feature(rustc_attrs)]` at the crate-level).
I would like this PR to get into nightly soon so that we can get early feedback in this release cycle and focus on correctness fixes and performance improvements, with the potential for removing the old backend implementation before beta branches off.
cc @rust-lang/compiler
