Provide tagged allocation top pointer

Provide tagged allocation top pointer

BUG=chromium:606711
LOG=N

[Michael Lippautz, 2016-04-28 07:51:38]

Patchset #1 (id:1) has been deleted

[Michael Lippautz, 2016-04-28 16:08:37]

Patchset #1 (id:20001) has been deleted

[Michael Lippautz, 2016-04-28 16:58:07]

mlippautz@chromium.org changed reviewers:
+ bmeurer@chromium.org, hpayer@chromium.org

[Michael Lippautz, 2016-04-28 16:58:08]

wdyt? ports still missing.

IIUC it would safe turbofan one instruction while all other compilers/platforms
would more or less need the same # of instructions.

https://codereview.chromium.org/1924223002/diff/40001/src/code-stub-assembler.cc
File src/code-stub-assembler.cc (right):

https://codereview.chromium.org/1924223002/diff/40001/src/code-stub-assembler...
src/code-stub-assembler.cc:372: Goto(&merge);
I have the feeling that we should've written a tag here ;) Bug?

https://codereview.chromium.org/1924223002/diff/40001/src/heap/spaces.h
File src/heap/spaces.h (right):

https://codereview.chromium.org/1924223002/diff/40001/src/heap/spaces.h#newco...
src/heap/spaces.h:1603: intptr_t top_;
Pointer arithmetic out of object bounds is undefined behavior. Let's dance
around this by using intptr_t. If we don't do this clang optimizes away a
nullptr check in MemoryChunk::UpdateHighWaterMark starting at -O2.

(Ideally Address would not be a pointer but an integer but that's another UB
story.)

https://codereview.chromium.org/1924223002/diff/40001/src/x64/macro-assembler...
File src/x64/macro-assembler-x64.cc (right):

https://codereview.chromium.org/1924223002/diff/40001/src/x64/macro-assembler...
src/x64/macro-assembler-x64.cc:4819: testl(result,
Immediate(kDoubleAlignmentMask - kHeapObjectTag));
Don't really like this one (and below) but also don't know a better way.

[Hannes Payer (out of office), 2016-04-29 14:13:31]

looking good from my side

https://codereview.chromium.org/1924223002/diff/40001/src/heap/spaces.h
File src/heap/spaces.h (right):

https://codereview.chromium.org/1924223002/diff/40001/src/heap/spaces.h#newco...
src/heap/spaces.h:1603: intptr_t top_;
On 2016/04/28 at 16:58:08, Michael Lippautz wrote:
> Pointer arithmetic out of object bounds is undefined behavior. Let's dance
around this by using intptr_t. If we don't do this clang optimizes away a
nullptr check in MemoryChunk::UpdateHighWaterMark starting at -O2.
> 
> (Ideally Address would not be a pointer but an integer but that's another UB
story.)

Oh boy!

https://codereview.chromium.org/1924223002/diff/40001/src/x64/macro-assembler...
File src/x64/macro-assembler-x64.cc (right):

https://codereview.chromium.org/1924223002/diff/40001/src/x64/macro-assembler...
src/x64/macro-assembler-x64.cc:4819: testl(result,
Immediate(kDoubleAlignmentMask - kHeapObjectTag));
On 2016/04/28 at 16:58:08, Michael Lippautz wrote:
> Don't really like this one (and below) but also don't know a better way.

I think that is fine. Maybe have a constant for that case, e.g.
kDoubleAlignmentMaskTagged or something like that.

[Benedikt Meurer, 2016-05-01 17:30:03]

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

[Benedikt Meurer, 2016-05-01 17:30:04]

Adding Enrico for the CodeStubAssembler review.

The x64 port looks good, modulo the result_end thing; bonus points if you can
resolve that. :-)

https://codereview.chromium.org/1924223002/diff/40001/src/x64/macro-assembler...
File src/x64/macro-assembler-x64.cc (right):

https://codereview.chromium.org/1924223002/diff/40001/src/x64/macro-assembler...
src/x64/macro-assembler-x64.cc:4918: decp(result_end);
Hm, who needs this result_end anyways? Shouldn't that also be returned as tagged
value?
To me it seems highly confusing that the result is tagged, but the result_end is
not (I suppose that was always the case, but since we're touching this now, it
might be worth fixing/removing).

[epertoso, 2016-05-02 08:20:39]

lgtm

[epertoso, 2016-05-02 08:21:03]

On 2016/05/02 at 08:20:39, epertoso wrote:
> lgtm

For code-stub-assembler.cc, that is.

[Benedikt Meurer, 2016-05-03 03:58:24]

LGTM from my side.

[Benedikt Meurer, 2016-05-03 03:59:41]

On 2016/05/03 03:58:24, Benedikt Meurer wrote:
> LGTM from my side.

Clicked Send too early... I wanted to add to that: You don't need to change
result_end in this CL, unless you want to. But in case you don't, please leave a
TODO there, that result_end should either also be tagged or removed.

[Michael Lippautz, 2016-05-18 11:01:36]

Patchset #3 (id:80001) has been deleted

[Hannes Payer (out of office), 2016-05-18 18:03:59]

lgtm

[Michael Lippautz, 2016-06-07 17:17:23]

Description was changed from

==========
Provide tagged allocation top pointer

BUG=chromium:606711
LOG=N
==========

to

==========
Provide tagged allocation top pointer

BUG=chromium:606711
LOG=N
==========