Closed
Bug 1355943
Opened 7 years ago
Closed 7 years ago
Constant fold typebarrier
Categories
(Core :: JavaScript Engine: JIT, enhancement)
Core
JavaScript Engine: JIT
Tracking
()
RESOLVED
FIXED
mozilla55
Tracking | Status | |
---|---|---|
firefox55 | --- | fixed |
People
(Reporter: evilpie, Assigned: evilpie)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
1.81 KB,
patch
|
h4writer
:
review+
|
Details | Diff | Splinter Review |
In the six-speed for-of test we end up with a typebarrier wrapping primitive constant. I think this is caused by scalar replacement, but I haven't investigated further. Removing a typebarrier for a constant sounds ok to me, when it can never fail.
Attachment #8857601 -
Flags: review?(hv1989)
Comment 1•7 years ago
|
||
Comment on attachment 8857601 [details] [diff] [review] Constant fold unnecessary type-barrier Review of attachment 8857601 [details] [diff] [review]: ----------------------------------------------------------------- Normally that should already be a NOP: http://searchfox.org/mozilla-central/rev/944f87c575e8a0bcefc1ed8efff10b34cf7a5169/js/src/jit/Lowering.cpp#2766 During type analysis we create a "Unbox + TypeBarrier" out of an "TypeBarrier" if the type is not the same. Given that type is the same we will not create that Unbox and being left with a TypeBarrier that during lowering becomes a NOP. As a result this shouldn't really make a meaningful impact, except maybe for removing them already and having to iterate over less MIR nodes? That is also why I r+, for that speculative small compilation speed win. ::: js/src/jit/MIR.cpp @@ +2279,5 @@ > + if (type == MIRType::Value || type == MIRType::Object) > + return this; > + > + if (!input()->isConstant() || input()->type() != type) > + return this; Minor nit: can you split this one into two tests?
Attachment #8857601 -
Flags: review?(hv1989) → review+
Assignee | ||
Comment 2•7 years ago
|
||
Thanks for you review. This actually makes a difference, because with that fold we can actually eliminate a branch that depends on the typebarrier. Just redefining in the lowering pass doesn't give us that.
Pushed by evilpies@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/16fdef50b6e3 Constant fold ion type-barrier. r=h4writer
Comment 4•7 years ago
|
||
(In reply to Tom Schuster [:evilpie] from comment #2) > Thanks for you review. This actually makes a difference, because with that > fold we can actually eliminate a branch that depends on the typebarrier. > Just redefining in the lowering pass doesn't give us that. Ah right. Good call.
Assignee | ||
Comment 5•7 years ago
|
||
While this sped up for-of and destructuring, other six-speed benchmarks regressed. I find that surprising.
Comment 6•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/16fdef50b6e3
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox55:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in
before you can comment on or make changes to this bug.
Description
•