1691154 - SIMD optimization x64/x86: Improve SIMD i32x4.trunc_sat_f64x2_u_zero

Status: REOPENED

(Core :: JavaScript: WebAssembly, enhancement, P5)

Description

[Yury Delendik (:yury)]

See https://phabricator.services.mozilla.com/D103959#inline-583275

Improve MacroAssemblerX86Shared::unsignedTruncSatFloat64x2ToInt32x4: "... implement versions of minpd, addpd, subpd, unpcklps, and andpd (used above) that take a constant operand, so that we can avoid the extra load instruction? It looks like we could also avoid the temp here with that, which is also nice."

Comment 1

[Yury Delendik (:yury)]

Attachment: WIP: Bug 1691154 - Improve SIMD i32x4.trunc_sat_f64x2_u_zero.

Comment 2

[Yury Delendik (:yury)]

There is no win in doing that: i32x4.trunc_sat_f64x2_u_zero performance stays the same on x86, or getting worse by 10% on x64 with my local benchmarks. I also tried i32x4.trunc_sat_f64x2_s_zero -- there was a win about 2% on x86. I think everything gets slower due to memory accesses.

Comment 3

[Yury Delendik (:yury)]

The loop of the test looks:

before

00000028 66 45 0f 57 ff xorpd %xmm15, %xmm15
0000002D 66 41 0f 5f c7 maxpd %xmm15, %xmm0
00000032 0f 28 15 97 00 00 00 movapsx 0x00000000000000D0, %xmm2
00000039 66 0f 5d c2 minpd %xmm2, %xmm0
0000003D 66 0f 3a 09 c0 0b roundpd $0x0B, %xmm0, %xmm0
00000043 0f 28 15 96 00 00 00 movapsx 0x00000000000000E0, %xmm2
0000004A 66 0f 58 c2 addpd %xmm2, %xmm0
0000004E 41 0f c6 c7 88 shufps $0x88, %xmm15, %xmm0

after

00000028 66 45 0f 57 ff xorpd %xmm15, %xmm15
0000002D 66 41 0f 5f c7 maxpd %xmm15, %xmm0
00000032 66 0f 5d 05 86 00 00 00 minpdx 0x00000000000000C0, %xmm0
0000003A 66 0f 3a 09 c0 0b roundpd $0x0B, %xmm0, %xmm0
00000040 66 0f 58 05 88 00 00 00 addpdx 0x00000000000000D0, %xmm0
00000048 41 0f c6 c7 88 shufps $0x88, %xmm15, %xmm0

Perhaps my test not giving enough pressure on registers to get enough benefits from the change. Lars, wdyt?

Comment 4

[Lars T Hansen [:lth]]

Yeah, good point. We would want the extra register pressure for sure to make a difference here. And then all we're saving is the one temp (and about eight bytes of code).

The alternative / complementary approach here is that we start discussing code generation that breaks constants out of these macro-ops so that they can be hoisted out of loops, ie, "legalizing" the operation early in the pipeline in a platform-dependent way to expose these constants to the MIR optimizer. But in that case we probably want machinery to un-hoist the constants again if register pressure gets high, and we don't have that yet.

I might P5 this bug instead of WONTFIXing it; leave it open until we have a handful of them and can consider our options with more background data.