Handle Strings and null/undefined in CacheIR bitwise operations
Categories
(Core :: JavaScript Engine: JIT, task, P2)
Tracking
()
People
(Reporter: anba, Assigned: anba)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
We don't have CacheIR support for string|0
, because it's already supported by Ion. For Warp we need to handle this at the CacheIR level. The same goes for null
and undefined
, which I've seen in user code like int32Array[invalidIndex] | 0
(bug 1515620).
Assignee | ||
Comment 1•4 years ago
|
||
Handle null
and undefined
to avoid the slow VM-call fallback for code like
int32Array[invalidIndex]|0
(bug 1515620).
Assignee | ||
Comment 2•4 years ago
|
||
string|0
is sometimes used as a "fast" way to convert strings to integers.
Ion handles this case, but Warp doesn't yet.
Depends on D90712
Assignee | ||
Comment 3•4 years ago
|
||
Extract the CanTruncateToInt32
and EmitTruncateToInt32Guard
functions in
preparation for the next part.
Depends on D90713
Assignee | ||
Comment 4•4 years ago
|
||
Use the same approach as taken for binary bitwise operations. This ensures no
unexpected performance differences can happen when switching between binary
and unary operations. This change also removes unreachable code in
UnaryArithIRGenerator::tryAttachStringNumber()
: If the input is a string,
we always succeed in tryAttachStringInt32()
, so the JSOp::BitNot
case in
tryAttachStringNumber()
is never taken. Furthermore this avoids attaching
the same stub multiple times in tryAttachStringInt32()
when the string can't
be parsed as an int32 (e.g. ~"1.1"
).
Depends on D90714
Updated•4 years ago
|
Comment 6•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/657a08a46195
https://hg.mozilla.org/mozilla-central/rev/c7fe96c53e6f
https://hg.mozilla.org/mozilla-central/rev/bb9a4a6710d1
https://hg.mozilla.org/mozilla-central/rev/1fc515ba6237
Updated•4 years ago
|
Description
•