Now instead of holding a native type based on the tag, all PrimVals
store a u64 (the `bits`), along with a `kind` corresponding to the
variant as it would be in the old PrimVal representation.
This commit makes no major optimizations and attempts to not change any
behaviour. There will be commits to follow that make use of this
representation to eliminate unnecessary allocation hacks like in
`value_to_primval`.
A number of places could be even more cleaned up after this commit,
particularly in `cast.rs`.
Previously, you could perform the following, if you assume we could make
`Cell<i32>` into a primitive. (Alternately, you could achieve this with
unsafe code):
x = Cell::new(12);
y = &x;
// Miri locals array:
// x = ByRef(alloc123);
// y = ByVal(Ptr(alloc123));
//
// Miri allocations:
// alloc123: [12, 0, 0, 0]
x.set(42);
// Miri locals array:
// x = ByVal(I32(42));
// y = ByVal(Ptr(alloc123));
//
// Miri allocations:
// alloc123: [12, 0, 0, 0]
Notice how `y` still refers to the allocation that used to represent
`x`. But now `x` was changed to `42` and `y` is still looking at memory
containing `12`.
Now, instead, we keep `x` as a `ByRef` and write the `42` constant into
it.
Unit test to follow in the next commit.
This helps in the case of field projections of the results of checked
binary operations. E.g.:
_1 = CheckedAdd(const 1i32, const 2i32);
assert(!(_1.1: bool), "attempt to add with overflow" -> bb1
Previously, the `_1.1` field projection lvalue would force_allocate `_1`
so it could read the memory in the old-style way. Now checked math with
its assertions will not allocate at all.
The oom2.rs compile-fail test had to be re-written, because the old
version of it no longer allocates _at all_ (yay!), so it would hit the
stack depth limit instead, from recursion.
Thanks to the `Value` locals refactoring, now primitive locals (ints,
floats, chars, bools, and the like) will not require `Allocation`s at
all, and locals that are never initialized at all because of conditional
control flow won't be wasting memory.
Previously ReturnPointer was just the first slot in the locals array,
which had type `Vec<Pointer>`. But after my recent refactoring, locals
is `Vec<Value>` and it became increasingly hacky to pull a pointer out
of the first slot to be the value. Besides, that hack wouldn't allow
ReturnPointer to ever be an `Lvalue::Local`, referring directly to a
local on a higher stack frame.
Now ReturnPointer has no presence in the locals array, instead being
upgraded to its own field on `Frame`.
This introduces a couple of new hacks, detailed by some of my FIXME
comments, so that I could get the tests passing again and commit. More
commits coming soon should clean up these hacks without much trouble,
and overall I feel that the code is converging on a cleaner, more
efficient design.
The new `Lvalue` has an additional form, `Lvalue::Local`, with the old
form being `Lvalue::Ptr`. In an upcoming commit, we will start producing
the new form for locals, and enable reading and writing of primitive
locals without ever touching `Memory`.
Statics should be able to get a similar treatment, where primitive
statics can be stored and accessed without touching `Memory`.
Turning locals into `Vec<Value>` will allow writing `PrimVal` results
directly into the locals array without creating `memory::Allocation`s
for every local.
This will entail passing around a generalized kind of `Lvalue` instead
of `Pointer`s for the destinations of operations. Replacing `Pointer`
with `Lvalue` is mostly done with this commit, but expanding `Lvalue`
will come later.
This commit turns every local from `Pointer` into `Value::ByRef(ptr)`.
Locals which are `Value::ByVal(prim_val)` will come in a later commit.
Instead, there will be a `Value::ByValPair` variant for holding fat pointers
(among other things) modelled after `OperandValue::Pair` in rustc's trans.
This reduces the number of allocations Miri makes drastically. The
`const_to_ptr` function was a lame hack that allocated for every since simple
constant, and all of those are avoided now, except for one extra allocation each
for string and bytestring literals which will be fixed in a followup commit.
There are a number of hacks such as `eval_operand_to_ptr` left over from this
commit, which will also be fixed in followup commits.
previously we moved to the target block *before* calling a function, so when inspecting
the stack, it appeared as if we were in the first statement of the next block.
This might create confusion, because attempting to execute a statement can cause
arbitrary stackframes to be added for the constants/statics/promoteds required by that
statement. Before this commit, the first statement of the last added stackframe was
executed immediately. Thus there was no way to inspect the state before that first
statement.
