| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Pass more `Copy` types by value.
There are a lot of locations where we pass `&T where T: Copy` by reference,
which should both be slightly less performant and less readable IMO.
This PR currently consists of three fairly self contained commits:
- passes `ty::Predicate` by value and stops depending on `AsRef<ty::Predicate>`.
- changes `<&List<_>>::into_iter` to iterate over the elements by value. This would break `List`s
of non copy types. But as the only list constructor requires `T` to be copy anyways, I think
the improved readability is worth this potential future restriction.
- passes `mir::PlaceElem` by value. Mir currently has quite a few copy types which are passed by reference, e.g. `Local`. As I don't have a lot of experience working with MIR, I mostly did this to get some feedback from people who use MIR more frequently
- tries to reuse `ty::Predicate` in case it did not change in some places, which should hopefully
fix the regression caused by #72055
r? @nikomatsakis for the first commit, which continues the work of #72055 and makes adding `PredicateKind::ForAll` slightly more pleasant. Feel free to reassign though
|
|
|
|
|
|
Dumb NRVO
This is a very simple version of an NRVO pass, which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place, we bail out. This avoids running a full "reaching definitions" dataflow analysis.
I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges.
r? @ghost
|
|
|
|
|
|
|
|
|
|
|
|
- Round to zero, and representable values cast directly.
- `NaN` goes to 0
- Values beyond the limits of the type are saturated to the "nearest value"
(essentially rounding to zero, in some sense) in the integral type, so e.g.
`f32::INFINITY` would go to `{u,i}N::MAX.`
|
|
...emulating `MutatingUseContext::Call`
|
|
|
|
r=nikomatsakis
Don't hold the predecessor cache lock longer than necessary
#71044 returns a `LockGuard` with the predecessor cache to callers of `Body::predecessors`. As a result, the lock around the predecessor cache could be held for an arbitrarily long time. This PR uses reference counting for ownership of the predecessor cache, meaning the lock is only ever held within `PredecessorCache::compute`. Checking this API for potential sources of deadlock is much easier now, since we no longer have to consider its consumers, only its internals.
This required removing `predecessors_for`, since there is no equivalent to `LockGuard::map` for `Arc` and `Rc`. I believe this could be emulated with `owning_ref::{Arc,Rc}Ref`, but I don't think it's necessary. Also, we continue to return an opaque type from `Body::predecessors` with the lifetime of the `Body`, not `'static`.
This depends on #71044. Only the last two commits are new.
r? @nikomatsakis
|
|
|
|
|
|
There is no `Arc::map` equivalent to `LockGuard::map`
|
|
Remove `BodyAndCache`
...returning to the original approach using interior mutability within `Body`. This simplifies the API at the cost of some uncontended mutex locks when the parallel compiler is enabled.
The current API requires you to either have a mutable reference to `Body` (`&mut BodyAndCache`), or to compute the predecessor graph ahead of time by creating a `ReadOnlyBodyAndCache`. This is not a good fit for, e.g., the dataflow framework, which
1. does not mutate the MIR
2. only sometimes needs the predecessor graph (for backward dataflow problems)
|
|
|
|
|
|
visit_place_base is just visit_local
r? @wesleywiser
|
|
Detect mistyped associated consts in `Instance::resolve`.
*Based on #71049 to prevent redundant/misleading downstream errors.*
Fixes #70942 by refusing to resolve an associated `const` if it doesn't have the same type in the `impl` that it does in the `trait` (which we assume had errored, and `delay_span_bug` guards against bugs).
|
|
|
|
|
|
|
|
Use `call` instead of `invoke` for functions that cannot unwind
The `FnAbi` now knows if the function is allowed to unwind. If a
function isn't allowed to unwind, we can use a `call` instead of an
`invoke`.
This resolves an issue when calling LLVM intrinsics which cannot unwind
LLVM will generate an error if you attempt to invoke them so we need to
ignore cleanup blocks in codegen and generate a call instead.
Fixes #69911
r? @eddyb
cc @rust-lang/wg-ffi-unwind
|
|
|
|
The `FnAbi` now knows if the function is allowed to unwind. If a
function isn't allowed to unwind, we can use a `call` instead of an
`invoke`.
This resolves an issue when calling LLVM intrinsics which cannot unwind
LLVM will generate an error if you attempt to invoke them so we need to
ignore cleanup blocks in codegen and generate a call instead.
|
|
|
|
|
|
|
|
rustc_target::abi: rename FieldPlacement to FieldsShape.
Originally suggested by @eddyb.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make `Visitor::visit_body` take a plain `&Body`
`ReadOnlyBodyAndCache` has replaced `&Body` in many parts of the code base that don't care about basic block predecessors. This includes the MIR `Visitor` trait, which I suspect resulted in many unnecessary changes in #64736. This reverts part of that PR to reduce the number of places where we need to pass a `ReadOnlyBodyAndCache`.
In the long term, we should either give `ReadOnlyBodyAndCache` more ergonomic name and replace all uses of `&mir::Body` with it at the cost of carrying an extra pointer everywhere, or use it only in places that actually need access to the predecessor cache. Perhaps there is an even nicer alternative.
r? @Nashenas88
|
|
|
|
|
|
|
|
asm! is left as a wrapper around llvm_asm! to maintain compatibility.
|
|
|
|
|
|
handle ConstKind::Unresolved after monomorphizing
fixes #70125
r? @bjorn3
|
|
|
|
|
|
r=RalfJung,eddyb
Fix ICE caused by truncating a negative ZST enum discriminant
Fixes #70114
r? @oli-obk or @RalfJung
|
