Add Simd128Value code stubs.

Add Simd128Value code stubs.

LOG=N
BUG=v8:4124
Committed: https://crrev.com/7ec8eccef4d0faac59e17374a13762349ae208d5
Cr-Commit-Position: refs/heads/master@{#34951}

[bbudge, 2016-02-18 01:53:39]

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

[bbudge, 2016-02-18 01:53:40]

I think I need this to do change-lowering in Turbofan. I'm following the example
of HeapNumber here.

[bbudge, 2016-02-18 02:40:39]

On 2016/02/18 01:53:40, bbudge wrote:
> I think I need this to do change-lowering in Turbofan. I'm following the
example
> of HeapNumber here.

For context, here's the CL (not ready for review) that needs this:
https://codereview.chromium.org/1693563004/

[Benedikt Meurer, 2016-02-18 05:12:26]

Please check HAllocate support for SIMD alignment first. Otherwise LGTM.

https://codereview.chromium.org/1706053002/diff/20001/src/code-stubs-hydrogen.cc
File src/code-stubs-hydrogen.cc (right):

https://codereview.chromium.org/1706053002/diff/20001/src/code-stubs-hydrogen...
src/code-stubs-hydrogen.cc:1220:
Add<HAllocate>(Add<HConstant>(Simd128Value::kSize),                   \
Not sure that HAllocate get's the alignment correct for Simd128Values, you might
want to check that first.

[Benedikt Meurer, 2016-03-13 19:09:39]

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

[Benedikt Meurer, 2016-03-13 19:09:39]

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

[Benedikt Meurer, 2016-03-13 19:09:39]

Looks good to me modulo (un)alignment. Forwarding to Enrico.

[bbudge, 2016-03-14 01:16:53]

On 2016/03/13 19:09:39, Benedikt Meurer - OOO wrote:
> Looks good to me modulo (un)alignment. Forwarding to Enrico.

I'm wondering if we even need alignment at this point. For single SIMD values on
the heap, we need 128 bit "un-alignment" - the map value located so that the 16
bytes following it are aligned. For typed arrays, there isn't a SIMD array type,
so we can't know to align it.

ia32, x64, arm64 all have unaligned load and store instructions, so we can just
use those instructions.

WDYT?

[epertoso, 2016-03-14 17:26:45]

On 2016/03/14 at 01:16:53, bbudge wrote:
> On 2016/03/13 19:09:39, Benedikt Meurer - OOO wrote:
> > Looks good to me modulo (un)alignment. Forwarding to Enrico.
> 
> I'm wondering if we even need alignment at this point. For single SIMD values
on the heap, we need 128 bit "un-alignment" - the map value located so that the
16 bytes following it are aligned. For typed arrays, there isn't a SIMD array
type, so we can't know to align it.
> 
> ia32, x64, arm64 all have unaligned load and store instructions, so we can
just use those instructions.
> 
> WDYT?

I think that if we can live with the additional latency, there's no reason to
make Allocate more complex.

[bbudge, 2016-03-21 14:42:56]

The CQ bit was checked by bbudge@chromium.org

[bbudge, 2016-03-21 14:42:56]

The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org
Link to the patchset: https://codereview.chromium.org/1706053002/#ps80001
(title: "Rebase.")

[commit-bot: I haz the power, 2016-03-21 14:43:07]

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

[commit-bot: I haz the power, 2016-03-21 14:43:09]

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

[commit-bot: I haz the power, 2016-03-21 14:43:10]

All required reviewers (with asterisk prefixes) have not yet approved this CL.

No L-G-T-M from a valid reviewer yet. 
CQ run can only be started by full committers or once the patch has
received an L-G-T-M from a full committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
Committers are members of the group "project-v8-committers".
Note that this has nothing to do with OWNERS files.

[bbudge, 2016-03-21 14:43:59]

The CQ bit was unchecked by bbudge@chromium.org

[bbudge, 2016-03-21 15:07:29]

On 2016/03/14 17:26:45, epertoso wrote:
> On 2016/03/14 at 01:16:53, bbudge wrote:
> > On 2016/03/13 19:09:39, Benedikt Meurer - OOO wrote:
> > > Looks good to me modulo (un)alignment. Forwarding to Enrico.
> > 
> > I'm wondering if we even need alignment at this point. For single SIMD
values
> on the heap, we need 128 bit "un-alignment" - the map value located so that
the
> 16 bytes following it are aligned. For typed arrays, there isn't a SIMD array
> type, so we can't know to align it.
> > 
> > ia32, x64, arm64 all have unaligned load and store instructions, so we can
> just use those instructions.
> > 
> > WDYT?
> 
> I think that if we can live with the additional latency, there's no reason to
> make Allocate more complex.

It looks like I need an l-g-t-m from you epertoso.

[epertoso, 2016-03-21 15:10:07]

lgtm

[bbudge, 2016-03-21 15:28:41]

The CQ bit was checked by bbudge@chromium.org

[commit-bot: I haz the power, 2016-03-21 15:28:54]

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

[commit-bot: I haz the power, 2016-03-21 15:45:38]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-03-21 15:47:07]

Description was changed from

==========
Add Simd128Value code stubs.

LOG=N
BUG=v8:4124
==========

to

==========
Add Simd128Value code stubs.

LOG=N
BUG=v8:4124

Committed: https://crrev.com/7ec8eccef4d0faac59e17374a13762349ae208d5
Cr-Commit-Position: refs/heads/master@{#34951}
==========

[commit-bot: I haz the power, 2016-03-21 15:47:10]

Patchset 5 (id:??) landed as
https://crrev.com/7ec8eccef4d0faac59e17374a13762349ae208d5
Cr-Commit-Position: refs/heads/master@{#34951}