Fix bugs in simplified lowering relating to int32/uint32 signs.

Fix bugs in simplified lowering relating to int32/uint32 signs.

Lowering of NumberToUint32 and NumberToInt32 was not correctly accounting for the sign of the input and the sign of the output, emitting the wrong representation changes.

Along the way, I've found cases where MachineOperatorBuilder would break if fed a machine type for loads or stores that was not cached, requiring MachineOperatorBuilder to take zone to allocate operators for these cases.

R=bmeurer@chromium.org, jarin@chromium.org
BUG=

Committed: https://code.google.com/p/v8/source/detail?r=25247

[Benedikt Meurer, 2014-11-10 12:54:46]

bmeurer@chromium.org changed reviewers:
+ bmeurer@chromium.org

[Benedikt Meurer, 2014-11-10 12:54:47]

https://codereview.chromium.org/714613002/diff/1/src/compiler/typer.cc
File src/compiler/typer.cc (right):

https://codereview.chromium.org/714613002/diff/1/src/compiler/typer.cc#newcod...
src/compiler/typer.cc:1037: if (FLAG_turbo_mod_range)
Why do we need a flag here? Maybe just enable this in a separate CL, which is
just 2 line fix, which we can easily revert if it breaks. Stuff that's behind a
flag is potentially broken because it doesn't get tested.

[titzer, 2014-11-10 12:57:07]

https://codereview.chromium.org/714613002/diff/1/src/compiler/typer.cc
File src/compiler/typer.cc (right):

https://codereview.chromium.org/714613002/diff/1/src/compiler/typer.cc#newcod...
src/compiler/typer.cc:1037: if (FLAG_turbo_mod_range)
On 2014/11/10 12:54:47, Benedikt Meurer wrote:
> Why do we need a flag here? Maybe just enable this in a separate CL, which is
> just 2 line fix, which we can easily revert if it breaks. Stuff that's behind
a
> flag is potentially broken because it doesn't get tested.

That was an oversight, I am removing the flag.

[Jarin, 2014-11-10 13:01:17]

lgtm

[Benedikt Meurer, 2014-11-10 13:01:25]

lgtm

[titzer, 2014-11-10 14:28:29]

Committed patchset #3 (id:40001) manually as 25247 (presubmit successful).