1206672 - SIMD: hoist the bounds check from instructions that check lane indexes

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine: JIT, defect, P5)

Description

[Benjamin Bouvier [:bbouvier] (inactive)]

As of today, SimdExtractElement and SimdInsertElement aren't emitted if any of the lane indexes isn't an int32 **at IonBuilding time**. That's sub-efficient: it could be emitted in all cases, would a range check be emitted for the lane inputs.

Also, SimdGeneralShuffle x86's codegen emits its own range check. Let's hoist this range check out of the SimdGeneralShuffle instruction, for more optimizations opportunities.

Comment 1

[Jakob Stoklund Olesen [:jolesen]]

Currently, asm.js requires lane indexes to be immediate integer operands, and for SIMD.js we only inline instructions with constant lane indexes, with the exception of shuffle/swizzle which map to the MSimdGeneralShuffle instruction.

Code generation for a dynamic lane index amounts to storing the vector to memory and using smaller load/store instructions to extract or rearrange the lanes. There is not much for us to optimize there, so I think the asm.js approach makes sense: If you have a dynamic lane index, just emit the corresponding memory operations in Emscripten. It's the code you would get anyway, and then Ion doesn't have to worry about these things.

It is possible in JS code to have a lane index that is not a known constant during inlining, but that is revealed to be a constant by subsequent Ion optimizations. I don't know how common that is? I would expect JS lane indexes to be immediate integers too most of the time.

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

SIMD.js is being removed (bug 1416723). This relates to MIR nodes which get removed with SIMD.js, so closing for now; we might consider this back later.