[turbofan] Avoid overflow checks on SpeculativeNumberAdd/Subtract/Multiply.

[turbofan] Avoid overflow checks on SpeculativeNumberAdd/Subtract/Multiply.

Keep the unrestricted feedback type around during retyping and use that
to check whether an overflow check is actually necessary when doing the
lowering of SpeculativeNumberAdd/Subtract/Multiply. If based on feedback
that is taken for the inputs we already know that the result of the
operation fits into Signed32 or Unsigned32 range, then we don't need to
perform any overflow checks.

R=mvstanton@chromium.org
BUG=v8:5267, v8:5270
Committed: https://crrev.com/17dbaff9c77c3a3d5a7248fe302a43ca0b51ec26
Cr-Commit-Position: refs/heads/master@{#39198}

[Benedikt Meurer, 2016-09-06 05:22:25]

The CQ bit was checked by bmeurer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-06 05:22:35]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Benedikt Meurer, 2016-09-06 05:24:13]

Hey Michael,

This change removes a bunch of unnecessary overflow checks that we
saw in various benchmarks (i.e. Kraken imaging benchmarks like this a
lot). Also avoids some duplication of logic between OperationTyper and
SimplifiedLowering itself (in the SpeculativeNumberMultiply case).
Please take a look.

Thanks,
Benedikt

[commit-bot: I haz the power, 2016-09-06 05:46:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-06 05:46:39]

Dry run: This issue passed the CQ dry run.

[mvstanton, 2016-09-06 08:55:29]

Let her rip :).
LGTM.

[Benedikt Meurer, 2016-09-06 09:06:16]

The CQ bit was checked by bmeurer@chromium.org

[commit-bot: I haz the power, 2016-09-06 09:06:21]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-06 09:08:35]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-09-06 09:09:10]

Description was changed from

==========
[turbofan] Avoid overflow checks on SpeculativeNumberAdd/Subtract/Multiply.

Keep the unrestricted feedback type around during retyping and use that
to check whether an overflow check is actually necessary when doing the
lowering of SpeculativeNumberAdd/Subtract/Multiply. If based on feedback
that is taken for the inputs we already know that the result of the
operation fits into Signed32 or Unsigned32 range, then we don't need to
perform any overflow checks.

R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
==========

to

==========
[turbofan] Avoid overflow checks on SpeculativeNumberAdd/Subtract/Multiply.

Keep the unrestricted feedback type around during retyping and use that
to check whether an overflow check is actually necessary when doing the
lowering of SpeculativeNumberAdd/Subtract/Multiply. If based on feedback
that is taken for the inputs we already know that the result of the
operation fits into Signed32 or Unsigned32 range, then we don't need to
perform any overflow checks.

R=mvstanton@chromium.org
BUG=v8:5267,v8:5270

Committed: https://crrev.com/17dbaff9c77c3a3d5a7248fe302a43ca0b51ec26
Cr-Commit-Position: refs/heads/master@{#39198}
==========

[commit-bot: I haz the power, 2016-09-06 09:09:10]

Patchset 1 (id:??) landed as
https://crrev.com/17dbaff9c77c3a3d5a7248fe302a43ca0b51ec26
Cr-Commit-Position: refs/heads/master@{#39198}

[Jarin, 2016-09-07 20:00:31]

I really do not like the unrestricted type field just like I was not wild about
the restriction type. This is two extra full general types in NodeInfo (without
any explanation what they are good for) just for the sake of a few nodes that
restrict typing in a very constrained way (only Signed32 or Number).

Also, there is a bug in the "optimization" for unsigned values. I believe you
just cannot skip the overflow check for unsigned values - to do that you would
have to propagate unsigned restricted type during retyping. It might be doable,
but I would really prefer not to go there; at least not without some serious
test+documentation+refactoring effort. It is not hard to construct a repro:

function f(a) {
  a++; 
  a = Math.max(0, a);
  a++;
  return a;
}

f(0);
f(0);
%OptimizeFunctionOnNextCall(f);
assertEquals(2147483648, f(2147483646));