Which forms of extending loads and truncating stores do we want?

[sunfishcode]

#135 adds a Load[Int64] and Store[Int64] which presumably load and store with a 64-bit memory location with no extension or truncation. If we do nothing else, we should clarify that this is the case, but we may also consider the following:

Split Load into Int32Load, Int64Load, Float32Load, Float64Load. They'd still support memory types (though the float versions would only support float memory types, and integer versions would only support integer types). This would:

• make a very clean way to have 8-bit and 16-bit loads which extend directly to Int64, so you don't have to do a 32-bit extending load and then separately extend to Int64
• add support for a single-operation 32-bit Load that extends to Int64
• make a nice space for Float16 loads that directly promote to Float32 or Float64 in the future
• minimize unnecessary differences between 32-bit code and 64-bit code

And analogous changes for Store.

I imagine the main argument against this will be redundancy in functionality. Why have operations that can be built out of other operations and pattern-matched in implementations (since it's often a single instruction)? My answers are that these operators will be very commonly used, and so they will be appreciated by humans reading the code, and they'll be easier for very-simple implementations to emit good code for.

[MikeHolman]

Seems reasonable, but wouldn't we still need opcodes for each legal permutation? If so I think we should still enumerate them. If this does impact opcode space I think we should limit the permutations further than you are suggesting, because for example Int32Load[Uint64] is unnecessary.

[lukewagner]

FWIW, having module-local index spaces should allow the compiler to order ops so that all the hot ops take a single byte (assuming a variable-length encoding of opcodes)). This is what makes me less worried about bloating our opcode space.

[MikeHolman]

Yeah, and I'm not all that concerned about opcode space (probably shouldn't have mentioned it), but I'd still prefer we avoid adding ops which are completely useless.

[lukewagner]

Definitely agreed about not having "dead" ops.

[titzer]

On Wed, Jun 10, 2015 at 9:15 PM, Dan Gohman notifications@github.com
wrote:

#135 WebAssembly/spec#135 adds a Load[Int64]
and Store[Int64] which presumably load and store with a 64-bit memory
location with no extension or truncation. If we do nothing else, we should
clarify that this is the case, but we may also consider the following:

Split Load into Int32Load, Int64Load, Float32Load, Float64Load. They'd
still support memory types (though the float versions would only support
float memory types, and integer versions would only support integer types).
This would:

That sounds reasonable for the heap, since there is one load per local
type. What about loading from globals? Right now they have a specified
memory type. It seems like we'd still need to have either local
extend/truncate operations for them or have Int32LoadGlobal,
Int64LoadGlobal, etc.

• make a very clean way to have 8-bit and 16-bit loads which extend
  directly to Int64, so you don't have to do a 32-bit extending load and then
  separately extend to Int64
• add support for a single-operation 32-bit Load that extends to Int64
• make a nice space for Float16 loads that directly promote to Float32
  or Float64 in the future
• minimize unnecessary differences between 32-bit code and 64-bit code

And analogous changes for Store.

I imagine the main argument against this will be redundancy in
functionality. Why have operations that can be built out of other
operations and pattern-matched in implementations (since it's often a
single instruction)? My answers are that these operators will be very
commonly used, and so they will be appreciated by humans reading the code,
and they'll be easier for very-simple implementations to emit good code for.

—
Reply to this email directly or view it on GitHub
WebAssembly/spec#139.

[lukewagner]

My expectation is that global variables would have (misnamed, perhaps) local types, not memory types.

[titzer]

On Thu, Jun 11, 2015 at 8:21 AM, Luke Wagner notifications@github.com
wrote:

My expectation is that global variables would have (misnamed, perhaps)
local types, not memory types.

Is there any particular reason for that? One view is that accesses to them
logically are loads and stores to memory, since they will need atomicity
annotations in the future.

—
Reply to this email directly or view it on GitHub
#139 (comment).

[lukewagner]

Good point. For MVP, I expect we don't even really need globals; before dynamic loading (and thus the need for a GOT), the only advantage they have is that they can't be aliased by loads/stores, but I expect that's insignificant (LLVM will have already taken advantage of this).

Once we have dynamic loading, the question is how to efficiently implement global data since you can't have modules just sticking their globals at fixed offsets in memory. The more I think about it, the more I think about variations from what is currently in AstSemantics.md (e.g., having globals just be aliased names for locations in the full heap that are auto-relocated and thus more efficient than what you could do otherwise) so I wonder if we should just take globals out of the MVP and make them part of the dynamic linking feature (or threads, which also hit upon the same issues via TLS and I hope have a symmetric solution).

[jfbastien]

@lukewagner sgtm.

I think TLS should be discussed separately from globals, though the solution may be similar. There are a bunch of different usecases for TLS, some of which we need to respect and some I hope to change.

Could you file bugs for both, capturing your thoughts?