Get rid of integer allocation

[RalfJung]

@eddyb mentioned that there are plans to get rid of the integer allocation (NEVER_ALLOC_ID). This is an attempt to summarize briefly what the plan is, and to document that such a plan exists. (I suppose the "refactor" label would make sense here?)

The idea is to change the "meaning" of the type Pointer to "pointers that actually point somewhere in memory". Every operation that also works on pointers obtained from integers should use a different type. They could either use PrimVal (but then these methods all have to handle undef...), or a new type that factors the Pointer and Bytes cases out of PrimVal, but cannot be Undef.

ptr-to-int-cast and their inverse literally become a noop on the data side. There is no longer any need to perform "normalization" in binary_op because all data now has a canonical representation. (The memory already does something like this, somewhat, by not adding any relocations when a pointer from the integer allocation is written to memory.)

Open questions:

• What about zero-sized types? We could either keep the ZST allocation, or make allocation return an integer when a ZST is allocated.
• Which name should the type that's either Pointer or just bytes have? PrimDefVal? I'm not good with names...

[oli-obk]

We can't remove the ZST allocation. If we did, we might have accidential conversions from integers to.zst pointers. I don't think it's much of an issue: zst pointers aren't handled specially as muh as integer pointers.

Wrt the naming: I think we should turn primval into two nested enums, the PrimVal type which is either Bytes or Pointer and a PrimDef type or sth which is either Undef or Def(PrimVal). This will make pattern matching as easy as it is now, and allow taking out the defined part without any additional effort.

[RalfJung]

So PrimDef is the thing that can be undefined? Sounds somewhat inintuitive to me. I mean, there's little chance this could be used incorrectly, but still.
Another option would be to use Option<PrimVal>. But using a dedicated type may be clearer.

[oli-obk]

You may rename PrimDef to anything you want ;) MaybeVal?

[oli-obk]

With Option it'll get messy since I think we do have some Option<PrimVal> in the code somewhere I think

[RalfJung]

If we were doing this from scratch, I'd probably call the current PrimDef Value, and call the current Value Variable or VariableValue or VariableVal or so.

[eddyb]

We don't use "variable" in MIR terminology for all locals. MIR trans would call it LocalRef.
I think LocalVal or LocalValue would work fine.

[RalfJung]

We don't use "variable" in MIR terminology for all locals.

I see.
Another option may be LocalState, because it describes the current state of a local. Unfortunately, that type sounds like it is talking about "local state" in general. I'd suggest Local if that was not already used for the thing identifying a local...

EDIT: My point here is that the ByRef case doesn't actually describe the value the local has -- that value is stored in memory can change without the Value (using current naming) changing. However, I will acknowledge that "state" doesn't really capture this much better than "value".

[oli-obk]

Local can be renamed to LocalId

[eddyb]

There's a reason MIR trans uses the FooRef convention, heh.

[RalfJung]

Where FooRef is the thing identifying a foo, or saying what state it currently has?

[eddyb]

The former, if I'm reading you right. It looks like it was borrowed from LLVM but it doesn't make much sense because there it's used in the C API for the types that are pointers to the C++ classes.

[RalfJung]

By "the thing identifying a local", I mean the integer which is an index into the list of locals. From the name, that's also what I expect a Ref to be. So then things would be called LocalRef/LocalId (newtype around integer) and Local (that's the by-ref/by-val/by-val-pair thing).

That is, assuming it is even worth renaming this stuff. That's why I said "if we started from scratch" above. ;)

[eddyb]

Oh, no, FooRef contains the rustc_trans/LLVM "instance" of mir::Foo.
So LocalRef contains the actual value, either an SSA immediate or an alloca.