-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Refactoring RefLayout #198
Conversation
aeneas/src/mach/MachLowering.v3
Outdated
|
||
var loads = Array<SsaInstr>.new(tn.size); | ||
|
||
for (i < loads.length) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, I think you only need to worry about handling partial reads for the last tn.sub[i]
. You can over-read for a field that is not too close to the end of a struct. We can do that optimization later and control it with a Fact
set on the instruction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm other than small comments
The RefLayout{Get/Set}Field opcodes (and their repeated counterparts) would read/write one byte at a time.
This PR introduces two new Opcodes that are created during normalization:
ByteArrayGetField[offset: int]<T>(arr: Array<byte>, i_offset: int) -> T
ByteArraySetField[offset: int]<T>(arr: Array<byte>, i_offset: int, value: T) -> void
All RefLayout reads/writes (including those for repeated fields) are normalized into this form.
When lowering to machine code, we decompose these loads/stores into power-of-two loads/stores (e.g. a
u56
, with 7 bytes, will be decomposed into loads of 4+2+1 bytes).Todo: