Add design/#986 (non-trapping float-to-int) to agenda

[lukewagner]

(I'm not sure if this is the process for adding something to the agenda; let's see :)

This issue has been coming up a lot lately; this seems like a quick fix we could make that could yield immediate improvements in usability and performance.

[jfbastien]

This would fit under performance, though having numbers and proposed semantics would be helpful.

Who's championing this?

Should we explore other non-trapping things, or just this one?

[sunfishcode]

I propose these semantics:

• i{32,64}.convert_{s,u}:sat/f{32,64}: positive overflow -> maximum integer, negative overflow -> minimum integer, NaN -> 0. Rationale: ARM, Java. NaN -> 0 is awkward, but other options are awkward too.

Key question: should the existing i{32,64}.convert_{s,u}/f{32,64} opcodes be used for this, or should new opcodes be added?

• Changing in place: It's unlikely to break compatibility in the real world, and there aren't currently any major producers requiring the trapping behavior, and it saves opcodes.
• New opcodes: Fully compatible, and it leaves the existing opcode in place which may have future uses, such as C# in a "checked" context, maybe Rust, C/C++ undefined-behavior checkers (eg. UBSan), or non-LLVM-based C/C++ compilers, could want the trapping opcode, especially if there's a trap handler feature in the future.

Float->int conversion is the only trapping operator that has gotten such attention at this point.

There aren't yet any observed performance problems. While there were reports about slowdowns, those were due to Emscripten using calls to imported JS functions. The code in Emscripten has since been changed, and I'm not aware of any reports since.

The main immediate concerns I'm aware of are:

• LLVM defines float-to-int conversion to be non-trapping (even though float-to-int conversion has full-aardvark UB in C/C++), so the current semantics will require it to insert extra code for conversions, which presumably has overhead which is desirable to avoid (though it hasn't yet been measured).
• Float-to-int conversion in the SIMD proposal would be the only trapping SIMD operation, and since it's common for hardware SIMD units to be non-trapping, it'd be nice to have wasm's base SIMD instruction set to be entirely non-trapping, to make it easier for hardware designers to implement it directly.

[sunfishcode]

Hardware ISA survey:

• ARM, and MIPS in NAN2008 mode, behave as proposed above.
• x86, and MIPS in "legacy FPU" mode, return the minimum integer in all exceptional cases.
• Power behaves as proposed above except NaN is converted to the minimum integer.
• RISC-V behaves as as proposed above except NaN is converted to the maximum integer.

[rossberg]

Relaxing the existing instructions sounds attractive. Especially since your hardware survey seems to imply that it would actually make them faster on some platforms, in which case I doubt that any producer would still want to use the trapping ones?

[lukewagner]

in which case I doubt that any producer would still want to use the trapping ones?

That was my impression as well.

Renaming seems like a good idea in case later it makes sense, for some other instruction, to have both trapping/saturating variants of the same logical operation.

[lukewagner]

So are we good to add this to the agenda (merge)?

[jfbastien]

I'd still like to know who's championing it, and will present. At the meeting I'll ask for performance numbers, and which other operations should have the same treatment. I'm OK merging the topic in with the understanding that these questions should be answered in the presentation.

[lukewagner]

I think @sunfishcode volunteered :)

[lukewagner]

On the topic of perf measurements: I think the high-order bit here is removing a source of unnecessary developer pain and for that we do have the "numbers" in the form of many independent people hitting this as Jukka was describing in design/#986. As long as it doesn't regress perf, we should do it; that it should improve perf by some indeterminate amount is just a cherry on top.

[jfbastien]

This issue has been coming up a lot lately; this seems like a quick fix we could make that could yield immediate improvements in usability and performance.

Was the original pitch. So it's not a performance proposal? I'd rather keep the meeting focused on performance TBH. Do you think this needs to happen soon, or could we wait until the subsequent meeting? With only 2 days I'm confident we can get through threads but am not sure SIMD will be done.

[lukewagner]

Yes, this should happen soon, especially if the conclusion is to change semantics. This is one of the few unnecessary problems many people seem to hit when switching from asm.js to wasm or using wasm for the first time. Also, there seems to already be some amount of consensus.

[lukewagner]

So, can we add this to the agenda? I don't expect it will take much time and it doesn't seem necessary to restrict the meeting to exclusively performance issues.

[jfbastien]

OK let's add this to the agenda. Can we timebox to 30 min or 1h between threads and SIMD? Can you update the PR accordingly?

[lukewagner]

rgr, PTAL

[rossberg]

On 18 May 2017 at 15:38, Luke Wagner ***@***.***> wrote: Renaming seems like a good idea in case later it makes sense, for some other instruction, to have both trapping/saturating variants of the same logical operation. Hm, renaming existing instructions would in fact be a breaking change (of

the text format) at this point. Better not do that.

[lukewagner]

Would it break anyone in practice, though?