Move 64-bit integer arithmetic to MVP.

[jfbastien]

The discussion in #81 leads me to believe that we mostly agree: WebAssembly should support 64-bit integer arithmetic in MVP, but not 64-bit heaps.

[lukewagner]

The discussion in #81 showed agreement that 64-bit ints should be available on all archs and probably made available well before >4gb heaps, not that it should be in the MVP. That's why int64 is currently in EssentialPostMVPFeatures.md.

[lukewagner]

In particular, int64 doesn't have an efficient polyfill.

[sunfishcode]

I don't have a strong opinion either way, but one could argue that the int64 polyfill wouldn't be too inefficient, and that an advantage of having it in the MVP is that we wouldn't have to have it live under a feature test in the future.

[jfbastien]

The polyfill will be as efficient as the code that e.g. LLVM generates for WebAssembly: it'll have to legalize 64-bit arithmetic to 32-bit. I don't think polyfill efficiency is an issue here.

I do think code complexity is an issue, though:

• With 64-bit integer arithmetic the polyfill must know how to legalize to 64-bit, and native support must support the operations (not that hard IMO).
• Without 64-bit integer arithmetic it's the compiler that generates WebAssembly code that must know how to do legalize.

If MVP doesn't have 64-bit arithmetic then once we do add 64-bit arithmetic developers will have to recompile to get efficient code, and their code will be bloated by all the legalized operations. I think these are downside we must consider.

[lukewagner]

I'm not an expert on int64 arith, but without mul64hi and other ops, won't emulated JS 64-bit arith be way slower than native support of int64 on 32-bit?

[lukewagner]

Ah, I think what you're saying is: if the source language has int64, then LLVM has to do something and it's no worse than what the polyfill would do.

[jfbastien]

@lukewagner exactly.

[MikeHolman]

I think we also want a way to extend/truncate between int32 and int64.

[jfbastien]

Good catch. Added:

• Int32FromInt64 - truncate a 64-bit signed integer to a 32-bit signed integer
• Int64FromInt32 - sign-extend a 32-bit signed integer to a 64-bit signed integer
• Uint64FromuInt32 - zero-extend a 32-bit unsigned integer to a 64-bit unsigned integer

I'm not in love with the names, but they're consistent with the other ones used.

[sunfishcode]

Also note that the signed versions are proposed to have an 'S' or 's' on them, per the part of #83 which seems to have consensus. And further renaming may also happen depending on the outcome of the rest of #83.

And we may also want to consider incorporting the nature of the conversion (truncate, promote, demote, int↔float, sext, zext, leading-bits truncate) instead of just saying "From" in all of these, but I don't yet have a specific proposal.

[jfbastien]

Yeah I'd prefer trunc/sext/zext instead of the names I used, but figured I stick with the current theme and we can bikeshed.

[MikeHolman]

LLVM has to do something and it's no worse than what the polyfill would do.

That was my general understanding as well, but I think we should look at what that something is and make sure we can reasonably replicate it in an unpacker before committing to int64 for MVP.

[lukewagner]

I'm fairly confident the polyfill will be able to emit something comparable to the int64 emulation done currently by Emscripten. I'm actually really liking this idea now. Furthermore, as JS gets int64 or, on a nearer timeframe, these ops that allow better emulation, than the polyfill can just feature test and use them.

[sunfishcode]

lgtm, with discussion of load/store to happen in another issue.

[MikeHolman]

nit: capitalization should be Uint64From_Ui_nt32. Also, other than this obvious typo, there is inconsistency in how the conversions are named with "UInt and Uint". As @sunfishcode said, these will probably have to be changed again, but should try to keep it consistent for now.

[jfbastien]

Will do after #122 lands (I'm waiting for it to finish this PR).

[kg]

I'm also on board with this. If we want to present a compelling option with wasm it's important for it to provide a better experience for users as time passes, without necessarily having to recompile existing applications. Putting int64 in earlier is an important move here since 64-bit arithmetic is a glaring weak spot in current compile-to-web solutions - when we 'flip the switch' and turn on native 64-bit in browser decoders (or the polyfill, for that matter) people using 64-bit arithmetic will instantly see huge performance gains without any effort on their end.

Also really valuable for compiler authors - implementing int64/uint64 yourself is a hassle so if wasm can do that for them in a centralized way, that's one more reason to target wasm instead of JS.

[kripken]

I am also in agreement here. This would provide the same level of support for 64-bit ints, basically, as Emscripten currently does. The only downside is the polyfill must contain code to emulate all 64-bit ops (but for anything not tiny, it's probably not a big deal) and the polyfill must be smart enough to be able to replace one instruction with several, as necessary (also not a big deal).

[jfbastien]

This PR is now merged with master after #122 went in.

[jfbastien]

@sunfishcode confirms this was good to go on IRC. Committing.