Bug 226676 - Optimize compareStrictEq when neither side is a double and at least one is neither a string nor a BigInt
Summary: Optimize compareStrictEq when neither side is a double and at least one is ne...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Robin Morisset
URL:
Keywords: InRadar
Depends on:
Blocks: 226786 227119
  Show dependency treegraph
 
Reported: 2021-06-04 22:06 PDT by Robin Morisset
Modified: 2021-06-18 12:40 PDT (History)
8 users (show)

See Also:


Attachments
Patch (28.51 KB, patch)
2021-06-04 23:00 PDT, Robin Morisset
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (29.46 KB, patch)
2021-06-05 08:19 PDT, Robin Morisset
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (29.39 KB, patch)
2021-06-05 10:41 PDT, Robin Morisset
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (29.48 KB, patch)
2021-06-05 11:45 PDT, Robin Morisset
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Morisset 2021-06-04 22:06:13 PDT
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.
Comment 1 Robin Morisset 2021-06-04 23:00:07 PDT
Created attachment 430646 [details]
Patch
Comment 2 Robin Morisset 2021-06-04 23:31:30 PDT
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.
Comment 3 Robin Morisset 2021-06-04 23:33:02 PDT
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.
Comment 4 Robin Morisset 2021-06-05 08:19:14 PDT
Created attachment 430649 [details]
Patch
Comment 5 Robin Morisset 2021-06-05 10:41:05 PDT
Created attachment 430651 [details]
Patch

Another attempt at fixing the 32-bit build.
Comment 6 Robin Morisset 2021-06-05 11:45:14 PDT
Created attachment 430654 [details]
Patch

Fixing yet another issue with 32-bits builds.
Comment 7 EWS 2021-06-07 12:55:36 PDT
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].
Comment 8 Radar WebKit Bug Importer 2021-06-07 12:56:21 PDT
<rdar://problem/78959047>