Bug 226676 – Optimize compareStrictEq when neither side is a double and at least one is neither a string nor a BigInt

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Robin Morisset]

NaN === NaN must return false, even if the bits are the same.
42 === 42.0 must return true, even if the bits are different
"foo" === "foo" must return true, even if the bits of the pointers to the strings are different
42n === 42n must return true, even if the bits of the pointers to the big integers are different

In all other cases we can do === by just comparing the bits of the JSValue

So we should speculate aggressively on this. According to profiling done by Phil, this optimization should be applicable to lots of functions in Speedometer2.

[Robin Morisset]

Created attachment 430646 [details]
Patch

[Robin Morisset]

Comment on attachment 430646 [details]
Patch

I just realized that the optimization is wrong in the case of HeapBigInt/BigInt32 if they are allowed to be equal.

I will put a guard with #if !USE(BIGINT32) around the part in DFGFixupPhase, then whenever I restore BIGINT32 I will have to either fix this optimization, or (more and more likely in my opinion) add an invariant that we never have small HeapBigInts when BigInt32 are available.

[Robin Morisset]

Comment on attachment 430646 [details]
Patch

I've also clearly broken the build on 32-bits, so taking this off the r? flag until I have fixed both problems.

[Robin Morisset]

Created attachment 430649 [details]
Patch

[Robin Morisset]

Created attachment 430651 [details]
Patch

Another attempt at fixing the 32-bit build.

[Robin Morisset]

Created attachment 430654 [details]
Patch

Fixing yet another issue with 32-bits builds.

[EWS]

Committed r278568 (238566@main): <https://commits.webkit.org/238566@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 430654 [details].

[Radar WebKit Bug Importer]

<rdar://problem/78959047>