Should load/store be typed and have sext/zext/trunc? about design HOT 3 CLOSED

On Tue, May 26, 2015 at 7:23 PM, JF Bastien [email protected]
wrote:

Filing this issue to capture a discussion
WebAssembly/spec#79 (comment) that
occurred in PR #79 WebAssembly/spec#79.

load/store are often spec'd as having an explicit type, and as being able
to implicitly sext/zext/trunc their inputs.

I'm wondering if instead load/store should:

• Be sized to N bytes, and require explicit type cast for load outputs
  and store input.
• Require implicit trunc for stores, and sext/zext for loads.

What happens when there is no sext/zext after loads? What is the type of
the N bytes read?

This is different from some compiler IRs, including LLVM's. However, the
current stated goal for this format is to keep it simple, and expect the
macro layer to capture redundancy. It seems like separating conversion,
extension and truncation out of load/store fits the goal.

Keeping this simple doesn't prevent optimization. It's pretty easy to
detect this pattern when doing instruction selection, if such an
instruction even exists on the target architecture. It does mean the IR has
lees magic, and is even easier to spec and implement in a dump interpreter.

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

from design.

IIUC, if we formalize validation as type checking (something that I think is attractive for multiple reasons), then we'd need special 1,2,4,8-byte types as the operands/result-types of load/store ops and the only other ops that would produce/consume these types would be the sext/zext/trunc ops. Thus, it doesn't seem like we'd be gaining much composability and, as a cost, we now have these irregular ops/types in our spec. We could identify the 4-byte int type with int32 and the 8-byte int type with int64, but that feels asymmetric (or pushes us to have int8/int16, something it seems noone is keen to do). So I don't see an elegance argument. Also, having irregular int8/int16 types could actually end up complicating a dumb compiler/interpreter, depending on how it was implemented. Lastly, I think it is a good goal to minimize the requisite number of "pattern matches assumed to be done by a baseline compiler to get good performance" to a minimum, and this would add several.

from design.

If we have int8 and int16, then we should do this. If we don't, then we shouldn't. I think we can close this issue and move any further discussion to #85.

from design.