x64 Assembler: Refactor `Location` to distinguish name/kind

[alexcrichton]

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 to Location::{eax, edx} for example which are two names for two different things, and this clashes because xmm{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 (r32a would 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

[abrown]

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 same LocationKind bucket? I guess so if we are only separating out the "need a new operand name" locations...

By the way, the &'static str would be used for more that Rust so we may just want to call it name?

[cfallin]

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 xmm1 vs. xmm2 both refer to the same pool of XMM registers but are encoding how the instruction uses them; while r32 vs eax refer to different register locations. Or to go by concrete code differences: r32 vs eax changes the regalloc constraints, while xmm1 vs xmm2 does not.

[alexcrichton]

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/Into impls 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