alexcrichton opened issue #10922:
We discussed this at today's Cranelift meeting but I wanted to write up my thoughts in an issue. @cfallin brought up that
Location::xmm{1,2,3}are a bit odd in that they are all the same thing conceptually just different names of the same thing. I brought up that this is in contracts toLocation::{eax, edx}for example which are two names for two different things, and this clashes becausexmm{1,2,3}are both valid physical register names.An alternative I think migth be possible is something like this:
struct Location { rust_field_name: &'static str, kind: LocationKind, } enum LocationKind { // ... everything we have today in `Location` minus r32a, r32b, xmm1/2/3 (collapsed to "xmm") } impl Location { const r32a: Location = Location { rust_field_name: "r32a", kind: LocationKind::r32 }; const xmm1: Location = Location { rust_field_name: "xmm1", kind: LocationKind::xmm }; // ... }That way we wouldn't actually need to change anything (
r32awould still work as a location) and we could perhaps refactor how fixed physical registers work to be all-caps ro some sort of similar convention to distinguish fixed register usages from non-fixed-register-usages (e.g. xmm1 vs XMM0)cc @abrown
alexcrichton added the cranelift:area:x64 label to Issue #10922.
abrown commented on issue #10922:
Yes, I think this all makes sense, but now I'm pondering the categorical question that @cfallin posed: should we treat the fixed locations (e.g.,
eax) differently than the generic ones (e.g.,r32) — should those continue live together in the sameLocationKindbucket? I guess so if we are only separating out the "need a new operand name" locations...By the way, the
&'static strwould be used for more that Rust so we may just want to call itname?
cfallin commented on issue #10922:
should we treat the fixed locations (e.g., eax) differently than the generic ones (e.g., r32)
Personally I think this makes sense still: fixed location is a property of the place the operand is stored, not its role for the instruction. So
xmm1vs.xmm2both refer to the same pool of XMM registers but are encoding how the instruction uses them; whiler32vseaxrefer to different register locations. Or to go by concrete code differences:r32vseaxchanges the regalloc constraints, whilexmm1vsxmm2does not.
alexcrichton commented on issue #10922:
By the way, the &'static str would be used for more that Rust so we may just want to call it name?
Oh I think we'd definitely want to bikeshed the above and consider some
From/Intoimpls to cut down on verbosity for sure, I mostly just wanted to make it clear that the name there is purely a construct for the generated Rust code
Last updated: Dec 06 2025 at 06:05 UTC