[turbofan] Bailout if LoadBuffer typing assumption doesn't hold.

[turbofan] Bailout if LoadBuffer typing assumption doesn't hold.

The LoadBuffer operator that is used for asm.js heap access claims to
return only the appropriate typed array type, but out of bounds access
could make it return undefined. So far we tried to "repair" the graph
later if we see that our assumption was wrong, and for various reasons
that worked for some time. But now that wrong type information that is
propagated earlier is picked up appropriately and thus we generate wrong
code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
thus get 2147483648 instead of 0 (with proper JS truncation).

This was always considered a temporary hack until we have a proper
asm.js pipeline, but since we still run asm.js through the generic
JavaScript pipeline, we have to address this now. Quickfix is to just
bailout from the pipeline when we see that the LoadBuffer type was
wrong, i.e. the result of LoadBuffer is not properly truncated and thus
undefined or NaN would be observable.

R=mstarzinger@chromium.org, jarin@chromium.org
BUG=chromium:589792
LOG=y

Committed: https://crrev.com/58ab990aa8c3aeee38e888c1c33404f4b5a14759
Cr-Commit-Position: refs/heads/master@{#34322}

[Benedikt Meurer, 2016-02-26 10:21:21]

Hey Michi, Jaro,

This is the back-mergable quick-fix that Michi suggested. It's the minimal thing
that we could do to mitigate the problem.
Please take a look.

Thanks,
Benedikt

Ben: FYI

[Michael Starzinger, 2016-02-26 10:45:28]

LGTM.

[Benedikt Meurer, 2016-02-26 10:45:52]

The CQ bit was checked by bmeurer@chromium.org

[commit-bot: I haz the power, 2016-02-26 10:46:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1740123002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1740123002/40001

[commit-bot: I haz the power, 2016-02-26 11:05:28]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-02-26 11:06:33]

Description was changed from

==========
[turbofan] Bailout if LoadBuffer typing assumption doesn't hold.

The LoadBuffer operator that is used for asm.js heap access claims to
return only the appropriate typed array type, but out of bounds access
could make it return undefined. So far we tried to "repair" the graph
later if we see that our assumption was wrong, and for various reasons
that worked for some time. But now that wrong type information that is
propagated earlier is picked up appropriately and thus we generate wrong
code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
thus get 2147483648 instead of 0 (with proper JS truncation).

This was always considered a temporary hack until we have a proper
asm.js pipeline, but since we still run asm.js through the generic
JavaScript pipeline, we have to address this now. Quickfix is to just
bailout from the pipeline when we see that the LoadBuffer type was
wrong, i.e. the result of LoadBuffer is not properly truncated and thus
undefined or NaN would be observable.

R=mstarzinger@chromium.org, jarin@chromium.org
BUG=chromium:589792
LOG=y
==========

to

==========
[turbofan] Bailout if LoadBuffer typing assumption doesn't hold.

The LoadBuffer operator that is used for asm.js heap access claims to
return only the appropriate typed array type, but out of bounds access
could make it return undefined. So far we tried to "repair" the graph
later if we see that our assumption was wrong, and for various reasons
that worked for some time. But now that wrong type information that is
propagated earlier is picked up appropriately and thus we generate wrong
code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
thus get 2147483648 instead of 0 (with proper JS truncation).

This was always considered a temporary hack until we have a proper
asm.js pipeline, but since we still run asm.js through the generic
JavaScript pipeline, we have to address this now. Quickfix is to just
bailout from the pipeline when we see that the LoadBuffer type was
wrong, i.e. the result of LoadBuffer is not properly truncated and thus
undefined or NaN would be observable.

R=mstarzinger@chromium.org, jarin@chromium.org
BUG=chromium:589792
LOG=y

Committed: https://crrev.com/58ab990aa8c3aeee38e888c1c33404f4b5a14759
Cr-Commit-Position: refs/heads/master@{#34322}
==========

[commit-bot: I haz the power, 2016-02-26 11:06:34]

Patchset 3 (id:??) landed as
https://crrev.com/58ab990aa8c3aeee38e888c1c33404f4b5a14759
Cr-Commit-Position: refs/heads/master@{#34322}