Revert of [turbofan] Insert dummy values when changing from None type.

Revert of [turbofan] Insert dummy values when changing from None type. (patchset #5 id:80001 of https://codereview.chromium.org/2266823002/ )

Reason for revert:
Octane/Mandreel aborts with an exception now:

TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function

Original issue's description:
> [turbofan] Insert dummy values when changing from None type.
>
> Currently we choose the MachineRepresentation::kNone representation for
> values of Type::None, and when converting values from the kNone representation
> we use "impossible" conversions that will crash at runtime. This
> assumes that the impossible conversions should never be hit (the only
> way to produce the impossible values is to perform an always-failing
> runtime check on a value, such as Smi-checking a string). Note that
> this assumes that the runtime check is executed before the impossible
> convesrion.
>
> Introducing BitwiseOr type feedback broke this in two ways:
>
> - we always pick Word32 representation for bitwise-or, so the
>   impossible conversion does not trigger (it only triggers with
>   None representation), and we could end up with unsupported
>   conversions from Word32.
>
> - even if we inserted impossible conversions, they are pure conversions.
>   Since untagging, bitwise-or operations are also pure, we could hoist
>   all these before the smi check of the inputs and we could hit the
>   impossible conversions before we get to the smi check.
>
> This CL addresses this by just providing dummy values for conversions
> from the Type::None type. It also removes the impossible-to-* conversions.
>
> BUG=chromium:638132
>
> Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
> Cr-Commit-Position: refs/heads/master@{#38883}

TBR=mstarzinger@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:638132
Committed: https://crrev.com/a55fdb1e7c19e2f9868190284df56bcf709dbf12
Cr-Commit-Position: refs/heads/master@{#38893}

[Benedikt Meurer, 2016-08-25 08:49:05]

The CQ bit was checked by bmeurer@chromium.org

[Benedikt Meurer, 2016-08-25 08:49:06]

Created Revert of [turbofan] Insert dummy values when changing from None type.

[commit-bot: I haz the power, 2016-08-25 08:49:18]

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-08-25 08:50:00]

Description was changed from

==========
Revert of [turbofan] Insert dummy values when changing from None type. (patchset
#5 id:80001 of https://codereview.chromium.org/2266823002/ )

Reason for revert:
Octane/Mandreel aborts with an exception now:

TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function

Original issue's description:
> [turbofan] Insert dummy values when changing from None type.
> 
> Currently we choose the MachineRepresentation::kNone representation for
> values of Type::None, and when converting values from the kNone representation
> we use "impossible" conversions that will crash at runtime. This
> assumes that the impossible conversions should never be hit (the only
> way to produce the impossible values is to perform an always-failing
> runtime check on a value, such as Smi-checking a string). Note that
> this assumes that the runtime check is executed before the impossible
> convesrion.
> 
> Introducing BitwiseOr type feedback broke this in two ways:
> 
> - we always pick Word32 representation for bitwise-or, so the
>   impossible conversion does not trigger (it only triggers with
>   None representation), and we could end up with unsupported
>   conversions from Word32.
> 
> - even if we inserted impossible conversions, they are pure conversions.
>   Since untagging, bitwise-or operations are also pure, we could hoist
>   all these before the smi check of the inputs and we could hit the
>   impossible conversions before we get to the smi check.
> 
> This CL addresses this by just providing dummy values for conversions
> from the Type::None type. It also removes the impossible-to-* conversions.
> 
> BUG=chromium:638132
> 
> Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
> Cr-Commit-Position: refs/heads/master@{#38883}

TBR=mstarzinger@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:638132
==========

to

==========
Revert of [turbofan] Insert dummy values when changing from None type. (patchset
#5 id:80001 of https://codereview.chromium.org/2266823002/ )

Reason for revert:
Octane/Mandreel aborts with an exception now:

TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function

Original issue's description:
> [turbofan] Insert dummy values when changing from None type.
> 
> Currently we choose the MachineRepresentation::kNone representation for
> values of Type::None, and when converting values from the kNone representation
> we use "impossible" conversions that will crash at runtime. This
> assumes that the impossible conversions should never be hit (the only
> way to produce the impossible values is to perform an always-failing
> runtime check on a value, such as Smi-checking a string). Note that
> this assumes that the runtime check is executed before the impossible
> convesrion.
> 
> Introducing BitwiseOr type feedback broke this in two ways:
> 
> - we always pick Word32 representation for bitwise-or, so the
>   impossible conversion does not trigger (it only triggers with
>   None representation), and we could end up with unsupported
>   conversions from Word32.
> 
> - even if we inserted impossible conversions, they are pure conversions.
>   Since untagging, bitwise-or operations are also pure, we could hoist
>   all these before the smi check of the inputs and we could hit the
>   impossible conversions before we get to the smi check.
> 
> This CL addresses this by just providing dummy values for conversions
> from the Type::None type. It also removes the impossible-to-* conversions.
> 
> BUG=chromium:638132
> 
> Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
> Cr-Commit-Position: refs/heads/master@{#38883}

TBR=mstarzinger@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:638132
==========

[commit-bot: I haz the power, 2016-08-25 08:50:00]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-08-25 08:50:30]

Description was changed from

==========
Revert of [turbofan] Insert dummy values when changing from None type. (patchset
#5 id:80001 of https://codereview.chromium.org/2266823002/ )

Reason for revert:
Octane/Mandreel aborts with an exception now:

TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function

Original issue's description:
> [turbofan] Insert dummy values when changing from None type.
> 
> Currently we choose the MachineRepresentation::kNone representation for
> values of Type::None, and when converting values from the kNone representation
> we use "impossible" conversions that will crash at runtime. This
> assumes that the impossible conversions should never be hit (the only
> way to produce the impossible values is to perform an always-failing
> runtime check on a value, such as Smi-checking a string). Note that
> this assumes that the runtime check is executed before the impossible
> convesrion.
> 
> Introducing BitwiseOr type feedback broke this in two ways:
> 
> - we always pick Word32 representation for bitwise-or, so the
>   impossible conversion does not trigger (it only triggers with
>   None representation), and we could end up with unsupported
>   conversions from Word32.
> 
> - even if we inserted impossible conversions, they are pure conversions.
>   Since untagging, bitwise-or operations are also pure, we could hoist
>   all these before the smi check of the inputs and we could hit the
>   impossible conversions before we get to the smi check.
> 
> This CL addresses this by just providing dummy values for conversions
> from the Type::None type. It also removes the impossible-to-* conversions.
> 
> BUG=chromium:638132
> 
> Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
> Cr-Commit-Position: refs/heads/master@{#38883}

TBR=mstarzinger@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:638132
==========

to

==========
Revert of [turbofan] Insert dummy values when changing from None type. (patchset
#5 id:80001 of https://codereview.chromium.org/2266823002/ )

Reason for revert:
Octane/Mandreel aborts with an exception now:

TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function

Original issue's description:
> [turbofan] Insert dummy values when changing from None type.
>
> Currently we choose the MachineRepresentation::kNone representation for
> values of Type::None, and when converting values from the kNone representation
> we use "impossible" conversions that will crash at runtime. This
> assumes that the impossible conversions should never be hit (the only
> way to produce the impossible values is to perform an always-failing
> runtime check on a value, such as Smi-checking a string). Note that
> this assumes that the runtime check is executed before the impossible
> convesrion.
>
> Introducing BitwiseOr type feedback broke this in two ways:
>
> - we always pick Word32 representation for bitwise-or, so the
>   impossible conversion does not trigger (it only triggers with
>   None representation), and we could end up with unsupported
>   conversions from Word32.
>
> - even if we inserted impossible conversions, they are pure conversions.
>   Since untagging, bitwise-or operations are also pure, we could hoist
>   all these before the smi check of the inputs and we could hit the
>   impossible conversions before we get to the smi check.
>
> This CL addresses this by just providing dummy values for conversions
> from the Type::None type. It also removes the impossible-to-* conversions.
>
> BUG=chromium:638132
>
> Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
> Cr-Commit-Position: refs/heads/master@{#38883}

TBR=mstarzinger@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:638132

Committed: https://crrev.com/a55fdb1e7c19e2f9868190284df56bcf709dbf12
Cr-Commit-Position: refs/heads/master@{#38893}
==========

[commit-bot: I haz the power, 2016-08-25 08:50:31]

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