810951 - IonMonkey: Use range information for compares

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Hannes Verschore [:h4writer]]

Range information can be used to remove if/else branches

Comment 1

[Hannes Verschore [:h4writer]]

Attachment: Part1: Add code for range analysis

This part adds the meat to do range analysis on compares and also to fold them during lowering

Comment 2

[Hannes Verschore [:h4writer]]

Attachment: Part2: Less restrictive when to fold + refactor to make easier to read

This is actually a very small change. We now also fold to LGoto when EmittedAtUses is false. As I see it, this check don't need to be true for folding. The rest is refactor to make more readable.

Note 1: both patches are to improve v8 score. I tried to run benchmarks, but due to fluctuating numbers hard to measure it. But I think v8 indeed has a small increase with these.
Note 2: both patches are separate and don't depend on each other.

Comment 3

[Jan de Mooij [:jandem]]

Can you find out which compares we are able to remove in V8/SS/Kraken with these patches? If there are some important expressions we can eliminate now that's awesome, but it's good to have some data on that before we add an optimization :)

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

+1 to comment #3, it would be good to know the exact effect especially with bug 766592 in flight.

Comment 5

[Hannes Verschore [:h4writer]]

A bit more info can't hurt indeed. I created it originally for #763958, but saw no speedup, although compare is getting removed.

Now before patch the tryFold wasn't used during lowering on SS, V8 and Kraken! So for these benchmarks that was dead code. After patch:

Kraken:
tests/kraken-1.1/stanford-crypto-ccm-data.js:20
tests/kraken-1.1/stanford-crypto-ccm-data.js:21
tests/kraken-1.1/stanford-crypto-pbkdf2-data.js:16
tests/kraken-1.1/stanford-crypto-sha256-iterative-data.js:16

V8:
/

SS:
/

Can't really see a difference in speed on kraken on this (or it would be in the noise) on x64. Overhead of cmp + jne in x86/x64 isn't that big, therefore expected?

Comment 6

[Hannes Verschore [:h4writer]]

Improvement is not big enough (nothing observed) to justify the added coded.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.