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.

[RalfJung]

Oh. That's odd naming to me... it's not a reference to a local then. I suppose they mean that it's the referent of a local.

[eddyb]

No it literally is cargo-culting the LLVM C API, because a SSA value is ValueRef.

[oli-obk]

I don't think we need the *Ref naming scheme in miri. Let's just stay with SomeThingId and SomeThing

[oli-obk]

Also I think renaming everything in a more sensible manner is fine. We do have RLS so any renaming should be trivial to do.

[eddyb]

(it's not like most renaming isn't just a multi-file regex replacement - I do those in my editor often)

That scheme doesn't work for things like mir::Lvalue, though, does it?

[oli-obk]

What do you mean? There's no need to rename rustc types. Also lvalue is not an ID. mir::Lvalue is the unresolved lvalue similar to a path, miri::Lvalue is the resolved lvalue containing pointers and such.

[eddyb]

If you already have miri::Foo for mir::Foo, why would you need FooId or anything of the sort?
I wonder if people would object to doing the former in rustc_trans.

[oli-obk]

Uhm we don't. I got it confused with Lvalue::Local. So no mass renaming necessary.

[RalfJung]

ah, right, mir::Local is in librustc. I forgot about that. Wouldn't it be somewhat confusing to then call the "state of a local" also Local, just in a different module? (This is regarding the proposal to rename the current PrimDef to Local.)
Given these circumstances, I guess I'll go with @eddyb here and prefer LocalVal.

[oli-obk]

We can't separate Undef from PrimVal, because a PrimVal for a ZST is Undef. Creating a new Zst variant makes no sense, because that has no additional purpose (we discussed that back when ZSTs were moved from always being ByRef to also making them ByVal).

[eddyb]

because a PrimVal for a ZST is Undef

What's wrong with Bytes(0) or anything else?

[oli-obk]

You might be able to do shenigans that end up reading it. But I can't think of any off the top of my head.

[RalfJung]

(we discussed that back when ZSTs were moved from always being ByRef to also making them ByVal).

Is that discussion available anywhere? I am asking because that would have been my suggestion: Make ZSTs always ByRef, after all, that doesn't even require an allocation. Just a pointer to the ZST allocation.

[oli-obk]

That was on IRC in rust-internals. search the log for eddyb saying undef I think

[RalfJung]

Do you remember a rough date? I have no idea whether I am looking for something that happened a month ago or a year ago. A brief search of the git history didn't turn up anything.

[oli-obk]

I have no clue. I can look in my local logs. But it was something about how zsts should never be read from anyway, so undef as zst makes more sense than a special zst value. But moving to byref to the zst alloc sounds good.

[eddyb]

Yeah the point is that the representation doesn't matter not that we should pick a specific one.

[RalfJung]

It matters insofar as we better be sure that any attempt to observe it throws an error. ;)

But moving to byref to the zst alloc sounds good.

Now you got me confused. Didn't you say above that this is how things used to be, and then they were changed, probably for a reason?

[oli-obk]

Yea it was changed. But I think that was part of other changes that were easier with that change happening, too

[RalfJung]

So some other things will get harder if we go back to "ZSTs are always ByRef"?

[oli-obk]

Yes. We'll have problems with follow_by_ref_value, but I just checked, we don't use it everywhere anymore. I guess we refactored all other uses out. Looks easily doable now, but it'll mean a zst can't be a primval anymore, not sure if we rely on that anywhere else.

[oli-obk]

I've done some work in this direction: oli-obk@e59ff23 still has some problems, since the pointers in lvalue need to be able to store integers, too.

[RalfJung]

the pointers in lvalue need to be able to store integers, too.

When does that arise? Sounds like an invalid lvalue to me, couldn't that error out instantaneously?

[RalfJung]

So you didn't end up even using a type that's just "Bytes or Ptr". Is handling the additional Undef case a problem anywhere?

[oli-obk]

Not yet. It might even be better to include it in some situations, because dereferencing and immediately referencing a pointer with undef value should fine

[RalfJung]

You mean like so?

fn main() {
    let x : *const i32 = unsafe { mem::uninitialized() };
    let y = unsafe { &*x };
}

So you are saying, Undef lvalues are fine? I suppose that's an option. That would also explain when "integer pointer" lvalues can arise.

[oli-obk]

Yes

[RalfJung]

Sounds reasonable. So the Lvalue::Ptr will change to take a PrimVal? And then I suppose the return lvalue can cease again to be an Option; Undef is covering that case just fine. Nice.