1355943 - Constant fold typebarrier

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, enhancement)

Description

[Tom S. (please needinfo tschuster)]

Attachment: Constant fold unnecessary type-barrier

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.

Comment 1

[Hannes Verschore [:h4writer]]

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?

Comment 2

[Tom S. (please needinfo tschuster)]

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.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/16fdef50b6e3
Constant fold ion type-barrier. r=h4writer

Comment 4

[Hannes Verschore [:h4writer]]

(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.

Comment 5

[Tom S. (please needinfo tschuster)]

While this sped up for-of and destructuring, other six-speed benchmarks regressed. I find that surprising.

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/16fdef50b6e3