Make sure fixed typed array is always double aligned for doubles

Make sure fixed typed array is always double aligned for doubles

Allows for getting rid of the special casing for float64 and is probably
faster.

BUG=v8:3996
R=verwaest@chromium.org,dslomov@chromium.org,plind44@gmail.com
LOG=n

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

[jochen (gone - plz use gerrit), 2015-05-05 14:44:42]

ptal

It seems like the hydrogen code missed the bits to double-align float64 bit
typed arrays. With my change, it should be no longer necessary to have the code
for unaligned double reads/writes

[Toon Verwaest, 2015-05-05 16:29:03]

lgtm

[Dmitry Lomov (no reviews), 2015-05-05 16:54:21]

lgtm

[Dmitry Lomov (no reviews), 2015-05-05 16:54:23]

lgtm

[paul.l..., 2015-05-05 17:17:18]

paul.lind@imgtec.com changed reviewers:
+ paul.lind@imgtec.com

[paul.l..., 2015-05-05 17:17:18]

I have some concerns here, can you hold a day, so that I can do some testing on
various MIPS platforms?

MIPS requires alignment of double fields, and we have workarounds (such as
READ_DOUBLE_FIELD) to accommodate  the fact that doubles are not always aligned
in 32-bit v8.

Previously we found that FixedDoubleArrays always start 8-byte aligned, but GC
can sometimes move that array to an unaligned offset. We did not find a suitable
fix at the time. 

I need to see if that can happen here, before we can remove the
READ_DOUBLE_FIELD.

[jochen (gone - plz use gerrit), 2015-05-05 18:20:09]

On 2015/05/05 at 17:17:18, paul.lind wrote:
> I have some concerns here, can you hold a day, so that I can do some testing
on various MIPS platforms?
> 
> MIPS requires alignment of double fields, and we have workarounds (such as
READ_DOUBLE_FIELD) to accommodate  the fact that doubles are not always aligned
in 32-bit v8.
> 
> Previously we found that FixedDoubleArrays always start 8-byte aligned, but GC
can sometimes move that array to an unaligned offset. We did not find a suitable
fix at the time. 
> 
> I need to see if that can happen here, before we can remove the
READ_DOUBLE_FIELD.

Cool, thanks!

[jochen (gone - plz use gerrit), 2015-05-05 19:01:10]

jochen@chromium.org changed reviewers:
+ hpayer@chromium.org

[jochen (gone - plz use gerrit), 2015-05-05 19:01:11]

+hpayer

Hannes, does GC ensure object alignment when we evacuate objects?

[Hannes Payer (out of office), 2015-05-05 20:22:50]

On 2015/05/05 19:01:11, jochen wrote:
> +hpayer
> 
> Hannes, does GC ensure object alignment when we evacuate objects?

It does not. You would have to enforce alignment in the MC code base and
un-align object with double fields and uneven number of header fields (to get
the full deal).

[paul.l..., 2015-05-06 03:24:18]

On 2015/05/05 20:22:50, Hannes Payer wrote:
> It does not. You would have to enforce alignment in the MC code base and
> un-align object with double fields and uneven number of header fields (to get
> the full deal).

Confirmed. In test-api/FixedFloat64Array on mips32 hardware, with GC, we require
the READ/WRITE_DOUBLE_FIELD workaround, as the double values are not aligned to
8. If I remove all the heap()->CollectAllGarbage() calls, then the test passes
with this CL.

[Hannes Payer (out of office), 2015-05-06 06:10:42]

I will have a look now how to integrate double alignment nicely in the allocator
https://code.google.com/p/chromium/issues/detail?id=436911

[paul.l..., 2015-05-07 03:10:43]

On 2015/05/06 06:10:42, Hannes Payer wrote:
> I will have a look now how to integrate double alignment nicely in the
allocator
> https://code.google.com/p/chromium/issues/detail?id=436911

Thanks for the changes, Hannes! This CL now works fine for MIPS.

[paul.l..., 2015-05-07 04:49:28]

lgtm

[jochen (gone - plz use gerrit), 2015-05-07 05:04:25]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2015-05-07 05:04:36]

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

[commit-bot: I haz the power, 2015-05-07 05:44:55]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-05-07 05:45:01]

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