[turbofan] Speculative optimize number operations with no feedback.

[turbofan] Speculative optimize number operations with no feedback.

Introduce a dedicated NumberOperationHint enum that represents the
feedback we can use for speculative number operations. On top of that
speculatively assume signed32 or number if we don't have any feedback
for a certain number operation yet (we choose signed32 as long as the
inputs can be signed32, otherwise we speculately choose number).

Also eliminate redundant speculative operators along the effect chain
during the load elimination phase. If we see a redundant speculative
number operation, we always use the dominating one, even if that type
feedback is different than ours.

R=jarin@chromium.org
BUG=v8:4930

[Benedikt Meurer, 2016-07-26 08:51:34]

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

[commit-bot: I haz the power, 2016-07-26 08:51:40]

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-07-26 08:52:49]

Hey Jaro,

Here's the type feedback speculation. Not using soft deopts for now, but we may
want to add that later.
Please take a look.

Thanks,
Benedikt

[commit-bot: I haz the power, 2016-07-26 09:06:42]

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

[commit-bot: I haz the power, 2016-07-26 09:06:42]

Dry run: Try jobs failed on following builders:
  v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...)
  v8_linux64_avx2_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...)

[Jarin, 2016-07-26 09:39:21]

This is a scary CL combining bunch of things - could we split it up into several
CLs? I am imagining:

- Unification of hints.
- None feedback handling.
- Redundancy elimination part.

https://codereview.chromium.org/2181743004/diff/1/src/compiler/redundancy-eli...
File src/compiler/redundancy-elimination.cc (right):

https://codereview.chromium.org/2181743004/diff/1/src/compiler/redundancy-eli...
src/compiler/redundancy-elimination.cc:143: template <typename Predicate>
Do we really need to have templates for this? How about passing a flag to the
compatibility check?

https://codereview.chromium.org/2181743004/diff/1/src/compiler/redundancy-eli...
File src/compiler/redundancy-elimination.h (right):

https://codereview.chromium.org/2181743004/diff/1/src/compiler/redundancy-eli...
src/compiler/redundancy-elimination.h:28: class EffectPathChecks final {
How about moving this class to the .cc file?

https://codereview.chromium.org/2181743004/diff/1/src/compiler/simplified-low...
File src/compiler/simplified-lowering.cc (right):

https://codereview.chromium.org/2181743004/diff/1/src/compiler/simplified-low...
src/compiler/simplified-lowering.cc:1112: hint =
NumberOperationHint::kNumberOrOddball;
I doubt this helps anything - if the type cannot be Signed32, then it would have
to be some funky type to benefit (such as minus-zero or NaN or bool). Perhaps it
would be best to keep it simple and always set Signed32 here.