Consider adding IC support for JSOp::Pos
Categories
(Core :: JavaScript Engine: JIT, enhancement, P1)
Tracking
()
People
(Reporter: anba, Assigned: anba)
References
(Blocks 1 open bug)
Details
Attachments
(7 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
https://phabricator.services.mozilla.com/D68869 reminded me that JSOp::Pos
doesn't have any IC support, which can show up when using +str
to convert strings to numbers [1].
[1] https://stackoverflow.com/questions/1133770/convert-a-string-to-an-integer#answer-43056963 mentions that +str
is slower in Firefox than for example str * 1
.
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
vm/Interpreter-inl.h:
IncOperation()
andDecOperation()
should use a non-mutable handle for their
val
parameter.
vm/Interpreter.cpp:
- It's not necessary to create two mutable handles for the same input value.
jit/BaselineIC.cpp:
jit/IonIC.cpp:
- Only when caling
BitNot()
andNegOperation()
we need to copy the input value.
Assignee | ||
Comment 3•5 years ago
|
||
tryAttachNumber()
can actually assert the result is a number when the input
is a number.
Depends on D69514
Assignee | ||
Comment 4•5 years ago
|
||
I've went with LoadInt32Result
and LoadDoubleResult
to match the existing
LoadObjectResult
CacheIR opcode.
The arguments jsop_binary_arith()
in IonBuilder::jsop_pos()
needed to be
swapped to match the requirements in arithUnaryBinaryCache()
.
Depends on D69515
Assignee | ||
Comment 5•5 years ago
|
||
Directly convert Strings to Int32 to make +int32AsString
faster and to be
able to have narrower type information for Ion/Warp. Without this change the
unary String ICs for Int32 results from the next part are actually slower than
the ICs for Double results.
emitGuardAndGetInt32FromString()
is based on the existing
emitGuardAndGetNumberFromString()
method.
Depends on D69516
Assignee | ||
Comment 6•5 years ago
|
||
emitGuardAndGetNumberFromString()
was changed to useScratchDoubleScope
,
becauseFloatReg0
isn't available for Unary ICs. (Lowering doesn't reserve it.)unaryArithTrySpecializedOnBaselineInspector()
now needs to filter String
values to avoid bailouts.
Depends on D69517
Assignee | ||
Comment 7•5 years ago
|
||
Ion doesn't use ICs for bit-not ~
with String inputs, which resulted in
+int32AsString
being noticeably faster than ~~int32AsString
. Handling
string indices makes ~~int32AsString
faster than the IC code, which is what
we'd normally expect.
Drive-by change:
- Reuse
SimpleBitOpOperand()
forbitnotTrySpecialized()
.
Depends on D69518
Assignee | ||
Comment 8•5 years ago
|
||
Depends on D69519
Comment 10•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/1c570e074172
https://hg.mozilla.org/mozilla-central/rev/cd56caa32ce4
https://hg.mozilla.org/mozilla-central/rev/a9112d79ed33
https://hg.mozilla.org/mozilla-central/rev/7adbc910ea0f
https://hg.mozilla.org/mozilla-central/rev/1a9370b327b7
https://hg.mozilla.org/mozilla-central/rev/6d84b6a7a8d1
https://hg.mozilla.org/mozilla-central/rev/933892439025
Updated•5 years ago
|
Description
•