Text format: parsing `v128.loadX_lane` and `v128.storeX_lane` requires backtracking about multi-memory

[rossberg]

I believe something similar happened before with table.init, when we moved to multiple tables.

We could require the (memory 0) syntax to spell out the memory, following the syntax we use in other places. But for consistency, we'd then have to do that on all load/store instructions, which would be rather tedious.

I think we could still change the syntax for lanes (say, to lane=0), but keep allowing the current syntax as backwards compat form that you can only use without a memory index. But I suppose that doesn't actually fix your problem, because that would come after...

[tlively]

I actually wouldn't mind having (memory X) everywhere, but I do agree it could get tedious. I also wouldn't mind keeping the backtracking for these instructions; it's not like they should come up a lot and the backtracking is fairly minor and well contained.

[tlively]

I just noticed that we already define memuse ::= '(' memory x:memidx ') in the text format, so it already exists if we want to use it for memory references in instructions as well.

[rossberg]

@tlively, yes, that's why I brought it up. But the tediousness argument still stands.

[tlively]

I just noticed that memory.init has a similar problem where e.g. figuring out whether the 5 in memory.init 5 is supposed to be a memory or data index requires backtracking.

Edit: ah, you already mentioned table.init, so I suppose this is already known. The difference is that memory.init is implemented in binaryen but table.init is not.

[titzer]

What about memory=N, to be more consistent with the offset=N syntax for load/store?