Change tag_field to FieldIdx in Variants::Multiple
#142005
Conversation
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
rustbot
added
A-LLVM
|
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri Some changes occurred to the CTFE machinery Some changes occurred in compiler/rustc_codegen_ssa |
|
oh sure. |
bors
added
S-waiting-on-bors
| @@ -26,7 +26,7 @@ impl<'tcx, M: Machine<'tcx>> InterpCx<'tcx, M> { | |||
| // No need to validate that the discriminant here because the | |||
| // `TyAndLayout::for_variant()` call earlier already checks the | |||
| // variant is valid. | |||
| let tag_dest = self.project_field(dest, tag_field)?; | |||
| let tag_dest = self.project_field(dest, tag_field.as_usize())?; | |||
There was a problem hiding this comment.
project_field should probably take FieldIdx... but that can be a future PR.
There was a problem hiding this comment.
IIRC this hits the problem that a bunch of these things are also used for arrays, and I've never dug in enough to know whether it's actually ok to convert a bunch of these things over to FieldIdx -- if this is used for [u8; 1 << 32] then the capped-at-0xFFFFFF00 FieldIdx wouldn't work.
(Though of course usize already doesn't work today either for cross-compiling to a 64-bit target from a 32-bit host, but I suspect that nobody actually ever does that so nobody's cared about it being broken.)
There was a problem hiding this comment.
project_field should not be used for arrays, we have project_index for that. (Those used to be one function but I refactored that a long time ago.)
There was a problem hiding this comment.
Oh, wait, InterpCx. I was thinking of https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.FieldsShape.html#method.offset and such.
If you say it'll work always here, I can give that a shot (in another PR).
There was a problem hiding this comment.
If you say it'll work always here
I think it should, but I can't be sure without just trying it myself.^^
There was a problem hiding this comment.
I was thinking of https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.FieldsShape.html#method.offset and such.
Yeah that should be cleaned up to separate field offsets from array element offsets.
Rollup of 11 pull requests Successful merges: - #141890 (Add link to correct documentation in htmldocck.py) - #141932 (Fix for async drop inside async gen fn) - #141960 (Use non-2015 edition paths in tests that do not test for their resolution) - #141968 (Run wfcheck in one big loop instead of per module) - #141969 (Triagebot: Remove `assign.users_on_vacation`) - #141985 (Ensure query keys are printed with reduced queries) - #141999 (Visit the ident in `PreciseCapturingNonLifetimeArg`.) - #142005 (Change `tag_field` to `FieldIdx` in `Variants::Multiple`) - #142017 (Fix incorrect use of "recommend" over "recommended") - #142024 (Don't refer to 'this tail expression' in expansion.) - #142025 (Don't refer to 'local binding' in extern macro.) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #142005 - scottmcm:fieldidx-in-variantsmultiple, r=workingjubilee Change `tag_field` to `FieldIdx` in `Variants::Multiple` It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field. This is a first part of pulling smaller pieces out of #138759, so r? workingjubilee
…-obk Update `InterpCx::project_field` to take `FieldIdx` As suggested by Ralf in rust-lang#142005 (comment)
Rollup merge of #142103 - scottmcm:fieldidx-in-interp, r=oli-obk Update `InterpCx::project_field` to take `FieldIdx` As suggested by Ralf in #142005 (comment)
Update `InterpCx::project_field` to take `FieldIdx` As suggested by Ralf in rust-lang/rust#142005 (comment)
Update `InterpCx::project_field` to take `FieldIdx` As suggested by Ralf in rust-lang/rust#142005 (comment)
Culprit PRs: - June 4: rust-lang/rust#141741 - June 5: rust-lang/rust#142015 - June 6: rust-lang/rust#138677, rust-lang/rust#142005 - June 7: rust-lang/rust#142012 - June 9: rust-lang/rust#141700 - June 10: rust-lang/rust#142179, rust-lang/rust#141803 Resolves #4140 By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
Allow `enum` and `union` literals to also create SSA values Today, `Some(x)` always goes through an `alloca`, even in trivial cases where the niching means the constructor doesn't even change the value. For example, <https://rust.godbolt.org/z/6KG6PqoYz> ```rust pub fn demo(r: &i32) -> Option<&i32> { Some(r) } ``` currently emits the IR ```llvm define align 4 ptr `@demo(ptr` align 4 %r) unnamed_addr { start: %_0 = alloca [8 x i8], align 8 store ptr %r, ptr %_0, align 8 %0 = load ptr, ptr %_0, align 8 ret ptr %0 } ``` but with this PR it becomes just ```llvm define align 4 ptr `@demo(ptr` align 4 %r) unnamed_addr { start: ret ptr %r } ``` (Of course the optimizer can clean that up, but it'd be nice if it didn't have to -- especially in debug where it doesn't run. This is like #123886, but that only handled non-simd `struct`s -- this PR generalizes it to all non-simd ADTs.) Doing this means handing variants other than `FIRST_VARIANT`, handling the active field for unions, refactoring the discriminant code so the Place and Operand parts can share the calculation, etc. Other PRs that led up to this one: - #142005 - #142103 - #142324 - #142383
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
This is a first part of pulling smaller pieces out of #138759, so
r? workingjubilee