A64: Eliminate static initializers

A64: Eliminate static initializers

R=rodolph.perfetta@arm.com, ulan@chromium.org
BUG=none
LOG=y

Committed: https://code.google.com/p/v8/source/detail?r=19156

[jochen (gone - plz use gerrit), 2014-02-05 22:52:15]

PTAL

I got rid of all initializers by:

1) replacing a computed constant with a preprocessor macro (e.g.
kSafepointSavedRegisters)
1a) actually computing the constant the right way (e.g. kHalfWordSizeInBytes)

2) deleting the code (e.g. Register::xregisters)

3) relentlessly violating strict aliasing rules (e.g. all registers)

The registers case is probably the most interesting one. CPURegister is now a
POD, so we can initialize it like CPURegister reg = { code, size, type }; It has
a template method As<T>() to down cast it to Register or FPRegister at runtime.
To define the Register/FPRegister constants at compile time, I use a similar
trick to define the constants to share the address with an previously
initialized CPURegister.

[Rodolph Perfetta (ARM), 2014-02-06 11:51:20]

https://codereview.chromium.org/143493006/diff/60001/src/a64/instructions-a64.h
File src/a64/instructions-a64.h (right):

https://codereview.chromium.org/143493006/diff/60001/src/a64/instructions-a64...
src/a64/instructions-a64.h:45: #define DEFINE_FLOAT(name, value) extern const
uint32_t name = value
did you mean to declare this extern and provide a value for it?

Anyway here we created a particular double from a bit pattern, you changed the
type to int so now the compiler will insert a cast and you'll get the double
conversion of the pattern not the bit pattern.

https://codereview.chromium.org/143493006/diff/60001/src/a64/instructions-a64...
src/a64/instructions-a64.h:46: #define DEFINE_DOUBLE(name, value) extern const
uint64_t name = value
same here.

https://codereview.chromium.org/143493006/diff/60001/src/a64/macro-assembler-...
File src/a64/macro-assembler-a64.cc (right):

https://codereview.chromium.org/143493006/diff/60001/src/a64/macro-assembler-...
src/a64/macro-assembler-a64.cc:4547: Fmov(Register(leftover_pcs),
FPRegister(leftover_arg));
FPRegister

[jochen (gone - plz use gerrit), 2014-02-06 11:59:47]

https://codereview.chromium.org/143493006/diff/60001/src/a64/instructions-a64.h
File src/a64/instructions-a64.h (right):

https://codereview.chromium.org/143493006/diff/60001/src/a64/instructions-a64...
src/a64/instructions-a64.h:45: #define DEFINE_FLOAT(name, value) extern const
uint32_t name = value
On 2014/02/06 11:51:21, Rodolph Perfetta (ARM) wrote:
> did you mean to declare this extern and provide a value for it?
> 
> Anyway here we created a particular double from a bit pattern, you changed the
> type to int so now the compiler will insert a cast and you'll get the double
> conversion of the pattern not the bit pattern.

no, that's not what will happen. The compiler will store the bit pattern in the
data segment, because I declared the store type as uint32_t/uint64_t

However, all sites that access the symbol will get the alternative definition
(line 48/49) which declares the store type as float/double. So the compiler
assumes that at this address, there is already a float/double and will just read
the bits without any conversion.

[Sven Panne, 2014-02-06 12:08:48]

https://codereview.chromium.org/143493006/diff/60001/src/a64/instructions-a64.h
File src/a64/instructions-a64.h (right):

https://codereview.chromium.org/143493006/diff/60001/src/a64/instructions-a64...
src/a64/instructions-a64.h:45: #define DEFINE_FLOAT(name, value) extern const
uint32_t name = value
http://media.giphy.com/media/3sjQViF0W1Mqs/giphy.gif
http://media.giphy.com/media/2K5uA7U4uZbVe/giphy.gif

;-) Couldn't resist...

[Rodolph Perfetta (ARM), 2014-02-06 12:16:00]

On 2014/02/06 11:59:47, jochen wrote:
>
https://codereview.chromium.org/143493006/diff/60001/src/a64/instructions-a64.h
> File src/a64/instructions-a64.h (right):
> 
>
https://codereview.chromium.org/143493006/diff/60001/src/a64/instructions-a64...
> src/a64/instructions-a64.h:45: #define DEFINE_FLOAT(name, value) extern const
> uint32_t name = value
> On 2014/02/06 11:51:21, Rodolph Perfetta (ARM) wrote:
> > did you mean to declare this extern and provide a value for it?
> > 
> > Anyway here we created a particular double from a bit pattern, you changed
the
> > type to int so now the compiler will insert a cast and you'll get the double
> > conversion of the pattern not the bit pattern.
> 
> no, that's not what will happen. The compiler will store the bit pattern in
the
> data segment, because I declared the store type as uint32_t/uint64_t
> 
> However, all sites that access the symbol will get the alternative definition
> (line 48/49) which declares the store type as float/double. So the compiler
> assumes that at this address, there is already a float/double and will just
read
> the bits without any conversion.

I see. Maybe a comment highlighting that the two variants of the macro used
different types would be good (it escaped me the first time).

[Rodolph Perfetta (ARM), 2014-02-06 12:16:18]

LGTM with nits addressed

[jochen (gone - plz use gerrit), 2014-02-06 13:17:50]

I added a comment.

The extern is necessary to keep the compiler from throwing away the symbol.

Sven, I'm happy to explain this to you if you don't get it :)

[jochen (gone - plz use gerrit), 2014-02-06 13:19:40]

Committed patchset #5 manually as r19156 (presubmit successful).