1241224 - Improve ranges at loop backedges

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Hannes Verschore [:h4writer]]

A long time ago I saw that we have some non-specific ranges on MPhi's in a loop. Now I finally found out why. For memory optimization we don't compute the Range of a MPhi if one of ranges of the operands is unknown.

When still doing this for phi's that have a backedge we get:

I[-2147483648 {#22}, 2147483647 {[loop] [phone]}] : Int32

Instead of the less precise:

F[? {#22}, ? {[loop] [phone]}] (U NaN U -Infinity U Infinity U -0) : Int32

Comment 1

[Hannes Verschore [:h4writer]]

Attachment: Patch

Comment 2

[Nicolas B. Pierron [:nbp]]

I am not sure to see where is the issue, would you have a test case where this matter?

From what I understand, the MPhi still has an Int32 type, and even if we do not attach a Range information, the type is still used to filter out ranges which cannot be represented, see Range::Range(const MDefinition*) [1].

[1] https://dxr.mozilla.org/mozilla-central/source/js/src/jit/RangeAnalysis.cpp#616

Comment 3

[Hannes Verschore [:h4writer]]

> function test() {
>   for (var i=0; i<1000000000; i++) { }
> }
> 
> test();

https://dxr.mozilla.org/mozilla-central/source/js/src/jit/RangeAnalysis.cpp#616
Is the reason why this is not needed in most cases. But for an MPhi that has a backedge this makes a difference. That is why I see the types mentioned in comment 0.

Comment 4

[Hannes Verschore [:h4writer]]

Attachment: bug1241224-ranges-at-phi

Like you said on irc, we are using the phi->range() somewhere. Here for the symbolic range analysis. We need a 'range()' that we can alter during the analysis, but we just take an empty range, instead of the output range. That is the reason we see the less precise range.

Comment 5

[Nicolas B. Pierron [:nbp]]

Comment on attachment 8710989 [details] [diff] [review]
bug1241224-ranges-at-phi

Review of attachment 8710989 [details] [diff] [review]:
-----------------------------------------------------------------

Good catch!

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7c02451fb069

Comment 7

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

https://hg.mozilla.org/mozilla-central/rev/7c02451fb069