-
Notifications
You must be signed in to change notification settings - Fork 831
Memory64Lowering: Handle -1 return value from memory.grow #6733
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
Conversation
This edge case make the lowering a little more tricky.
kripken
left a comment
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.
IIUC this is doing "if we get i32(-1), return i64(-1), else return u64(result)"? Can we not do "s64(result)"?
- If the result is -1 then sign-extending it works properly.
- If the result is the number of pages then sign-extending may be wrong if the sign bit was set. But can it be set? That would imply we allocated
2^31pages of size2^16which is 47 bits... surely that is over the limit? 😄
e937766 to
0215780
Compare
I guess that could work?
If we ever get variable sized pages I guess that would break? |
Should we keep it simple and use signed extension in this case rather than this complex code block? At the risk of breaking if we ever gets byte-sized pages? |
|
Oh, good point, yeah, if we use variable-sized pages then we might have 1-byte pages... In which case Let's keep the code you've already written, given that. It's not that complicated and it is future-proof. |
|
Wait, how would byte-sized pages work? It seems like |
Good point. We should probably raise this on the variable page size repo. |
Its only the special -1 value (0xffffffff) that is ear marked as an error... so this would just mean that under wasm32 you would only be able to grow your single-byte page-size memory to MAX_UINT32-1 rather than MAX_UINT32. That doesn't seem so bad does it? |
|
Noted in an upstream issue: WebAssembly/custom-page-sizes#28 Yeah, maybe the idea is that when the page size is small you only use wasm32? But it seems like in general there are use cases that could involve wasm64. |
With a 64-bit memory, memory.grow takes i64 and returns i64 |
|
Oh, right, the issue is that this is for the lowering pass where the input is "unnaturally" an i32. I'll close that issue then. |
This edge case make the lowering a little more tricky.