Allow MaybeUninit in input and output of inline assembly #114790
Conversation
rustbot
added
S-waiting-on-review
|
The real property we care about here is that this is a |
Hmm, I think this PR is fine on this because it targets only MaybeUninit, not arbitrary union or |
taiki-e
force-pushed
the
asm-maybe-uninit
branch
from
5971003
to
9be6925
Compare
| ty::Adt(adt, args) if Some(adt.did()) == self.tcx.lang_items().maybe_uninit() => { | ||
| let fields = &adt.non_enum_variant().fields; | ||
| let ty = fields[FieldIdx::from_u32(1)].ty(self.tcx, args); | ||
| let ty::Adt(ty, args) = ty.kind() else { unreachable!() }; | ||
| assert!(ty.is_manually_drop()); | ||
| let fields = &ty.non_enum_variant().fields; | ||
| let ty = fields[FieldIdx::from_u32(0)].ty(self.tcx, args); | ||
| self.get_asm_ty(ty, expr, is_input)? | ||
| } |
There was a problem hiding this comment.
We can support MaybeUninit<MaybeUninit<...>> (nested MaybeUninit) by moving this arm to the get_asm_ty function, should we support that?
(I don't know of any specific use cases where supporting it would be useful.)
taiki-e
force-pushed
the
asm-maybe-uninit
branch
from
9be6925
to
f49c2d0
Compare
taiki-e
force-pushed
the
asm-maybe-uninit
branch
from
f49c2d0
to
03fd2d4
Compare
|
@bors r+ |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (97fff1f): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 635.819s -> 634.534s (-0.20%) |
Motivation:
As part of the work to remove UBs from crossbeam's AtomicCell, I'm writing a library to implement atomic operations on MaybeUnint using inline assembly (atomic-maybe-uninit, crossbeam-rs/crossbeam#1015).
However, currently, MaybeUnint cannot be used in input&output of inline assembly, so when processing MaybeUninit, values must be passed through memory. It is inefficient and microbenchmarks have actually shown significant performance degradation.
It would be nice if we could allow MaybeUninit in input and output of inline assembly.
This PR changed the type check in rustc_hir_analysis to allow
MaybeUnint<int | float | ptr | fn ptr | simd vector>in input and output of inline assembly and added a simple test.To be honest, I'm not sure that this is the correct way to do it, because this is like doing transmute to integers/floats/etc from MaybeUninit on the compiler side. EDIT: this seems fine
r? @Amanieu
cc @thomcc (because you had previously proposed this)