Update AstSemantics.md #366
Conversation
|
|
||
| Linear memory access is accomplished with explicit `load` and `store` operations that | ||
| accept as input an `index` operand that is interpreted as a unsigned byte offset into the | ||
| linear memory. |
There was a problem hiding this comment.
They accept as input an index and an offset which are described in the Addressing section immediately following this section.
|
lgtm, other than a comment above. |
|
I just removed the references to indexing, since they are redundant with On Wed, Sep 23, 2015 at 3:19 PM, Dan Gohman [email protected]
|
Add back extending load/stores for 64-bit integers.
|
This PR undoes the explicit change in #326/#341/spec/#55 that @rossberg-chromium proposed and everyone (including you) lgtm'd which was to avoid including every possible coercion-on-load except those that were necessary to avoid introducing unwanted intermediate types (int8/int16). I don't have a strong opinion either way, but the change was intentional and we'll need to revise spec/ (again) with this design change. |
|
It was an oversight on my part to not notice that the coercions for i64 I think it's important to keep them since otherwise load/stores working On Thu, Sep 24, 2015 at 5:05 PM, Luke Wagner [email protected]
|
|
Ok; this is just the usual pattern-match vs. EITBI argument. I generally lean to the latter, so I guess I'm actually happy to see this PR; I mostly just wanted to point out that the change wasn't accidental (at least for some). I can update |
|
Btw: if you search AstSemantics.md there is only one more dangling reference to memory type (in Addressing) and then we could remove "Memory type". |
Tidy up references to memory type after #366
It looks like loads and stores of i64 with sizes < 64bits got dropped on the floor. This PR adds them back and revises the text to no longer refer to memory types.