[turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR deconstruction early an…

[turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR deconstruction early and remove type propagation.".

We have to reland these two commits at once, because the first breaks
some asm.js benchmarks without the second. The change was reverted
because of bogus checks in the verifier, which will not work in the
presence of OSR (and where hidden because of the type back propagation
hack in OSR so far). Original messages are below:

[turbofan] Add new JSFrameSpecialization reducer.

The JSFrameSpecialization specializes an OSR graph to the current
unoptimized frame on which we will perform the on-stack replacement.
This is used for asm.js functions, where we cannot reuse the OSR
code object anyway because of context specialization, and so we could as
well specialize to the max instead.

It works by replacing all OsrValues in the graph with their values
in the JavaScriptFrame.

The idea is that using this trick we get better performance without
doing the unsound backpropagation of types to OsrValues later. This
is the first step towards fixing OSR for TurboFan.

[turbofan] Perform OSR deconstruction early and remove type propagation.

This way we don't have to deal with dead pre-OSR code in the graph
and risk optimizing the wrong code, especially we don't make
optimistic assumptions in the dead code that leaks into the OSR code
(i.e. deopt guards are in dead code, but the types propagate to OSR
code via the OsrValue type back propagation).

BUG=v8:4273
LOG=n
R=jarin@chromium.org

Committed: https://crrev.com/ef661b080426d88be188342b4d8b9df3edd49026
Cr-Commit-Position: refs/heads/master@{#29486}

[Benedikt Meurer, 2015-07-06 10:28:56]

Hey Jaro,

Reland the whole beast. verifier was wrong on the JSForInStep and JSForInDone
with OSR because we don't have the static type info there which we asserted. But
still it is safe, since the OsrValue is always a SMI (it's completely controlled
by fullcodegen). Otherwise it's identical to the previous CLs.
Please take a look.

Thanks,
Benedikt

[Jarin, 2015-07-06 10:34:49]

lgtm

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

https://codereview.chromium.org/1226673005/diff/1/src/compiler/verifier.cc#ne...
src/compiler/verifier.cc:588: // visible, so we now it is safe (fullcodegen has
an unsigned smi there).
now -> know (here and below)

[Benedikt Meurer, 2015-07-06 10:37:39]

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

https://codereview.chromium.org/1226673005/diff/1/src/compiler/verifier.cc#ne...
src/compiler/verifier.cc:588: // visible, so we now it is safe (fullcodegen has
an unsigned smi there).
On 2015/07/06 10:34:49, jarin wrote:
> now -> know (here and below)

Done.

[Benedikt Meurer, 2015-07-06 10:37:44]

The CQ bit was checked by bmeurer@chromium.org

[Benedikt Meurer, 2015-07-06 10:37:44]

The patchset sent to the CQ was uploaded after l-g-t-m from jarin@chromium.org
Link to the patchset: https://codereview.chromium.org/1226673005/#ps20001
(title: "Address now -> know.")

[commit-bot: I haz the power, 2015-07-06 10:37:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1226673005/20001

[commit-bot: I haz the power, 2015-07-06 11:11:19]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-07-06 11:11:37]

Patchset 2 (id:??) landed as
https://crrev.com/ef661b080426d88be188342b4d8b9df3edd49026
Cr-Commit-Position: refs/heads/master@{#29486}