- User Since
- Jul 3 2019, 10:12 AM (7 w, 1 d)
Tue, Aug 13
The old path-based approach is slow for most operations, while the new pointer-based approach is fast for the most common ones.
For read/write/update operations, it is enough to check the pointer and at most a single descriptor to ensure whether the operation
can be performed. For some operations, such as some pointer comparisons, in the worst case the old-style path can be reproduced by
following the pointers produced through the getBase method, allowing us to implement everything.
updated diff, implemented requested changes
Implemented @zygoloid's suggestions
Sun, Aug 4
Implemented suggestions from @rsmith.
Wed, Jul 31
I have applied most of the changes you suggested to my HEAD which had significantly more functionality, including a replacement of Opcodes.in with TableGen.
Quite a few of your concerns are answered by the features I have added between submitting the patch and now. The interpreter now stands at ~6k LOC.
removed redundant check
replaced char with signed char
Just checked: tests pass with UBSan.
Updated comments about bitcast
Tue, Jul 30
Mon, Jul 29
We can add a separate integer type which tracks all the additional information required by __builtin_constant_p and compile all integers to it in this context. A later patch added an APInt fallback to the interpreter if an integral cannot be mapped to a type supported by the VM - this mechanism could be used to implement the fallback for contexts which cast pointers to integers.
How do you intend to represent pointers cast to integer types? Allocating 64 bits of state for a 64-bit integer is insufficient to model that case.
Jul 8 2019
Fixed read of call stack depth
Jul 3 2019
Fixed typo in command line flags