[turbofan] Add type to the allocation operator.

[turbofan] Add type to the allocation operator.

This gives us more precise type information, so we can avoid some type
guards to refine the type information back.

The motivation for this is to help escape analysis by not introducing
redundant type guards (which escape analysis cannot handle yet even
though it could and should do).

Motivating example:

In the example below, the out-of-object property array for properties
fld5 and fld6 gets type Any when it is created by "o.fld5 = 5" (for
object literals, we store 4 properties in-objeca, the rest goes out
of object).

When we run load elimination for the load the out-of-object property
array (to store 6 into o.fld6), load elimination inserts TypeGuard to
enforce the Type::Internal() type. This makes escape analysis bail out
on this object, and we do not eliminate the object creation.

function f() {
  var o = {};
  o.fld1 = 1;
  o.fld2 = 2;
  o.fld3 = 3;
  o.fld4 = 4;
  o.fld5 = 5;
  o.fld6 = 6;
}

f();
f();
%OptimizeFunctionOnNextCall(f);
f();

Review-Url: https://codereview.chromium.org/2797993006
Cr-Commit-Position: refs/heads/master@{#44470}
Committed: https://chromium.googlesource.com/v8/v8/+/e97b29a4c5741f11318416877fc43c3c8cea93a2

[Jarin, 2017-04-06 11:52:30]

The CQ bit was checked by jarin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-06 11:52:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Jarin, 2017-04-06 11:58:08]

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

[Jarin, 2017-04-06 11:58:08]

Could you take a look, please?

[Benedikt Meurer, 2017-04-06 12:08:05]

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/js-native-...
File src/compiler/js-native-context-specialization.cc (right):

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/js-native-...
src/compiler/js-native-context-specialization.cc:1523:
simplified()->Allocate(Type::Number(), NOT_TENURED),
This should be Type::OtherInternal(). A MutableHeapNumber is not a HeapNumber.

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/js-native-...
src/compiler/js-native-context-specialization.cc:2212:
simplified()->Allocate(Type::Internal(), NOT_TENURED),
Nit: Type::OtherInternal()

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
File src/compiler/simplified-operator.cc (right):

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
src/compiler/simplified-operator.cc:900: if (Type::Any()->Is(type)) {
I'd rather remove the caching completely. We don't allocate a lot of Allocator
operators usually.

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
File src/compiler/simplified-operator.h (right):

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
src/compiler/simplified-operator.h:248: struct AllocationParameters {
Nit: AllocateParameters

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
src/compiler/simplified-operator.h:249: Type* type;
Can we please stick to classes here?

[Jarin, 2017-04-06 14:40:56]

The CQ bit was checked by jarin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-06 14:41:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Jarin, 2017-04-06 15:11:08]

The CQ bit was checked by jarin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-06 15:11:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Jarin, 2017-04-06 15:11:29]

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/js-native-...
File src/compiler/js-native-context-specialization.cc (right):

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/js-native-...
src/compiler/js-native-context-specialization.cc:1523:
simplified()->Allocate(Type::Number(), NOT_TENURED),
On 2017/04/06 12:08:05, Benedikt Meurer wrote:
> This should be Type::OtherInternal(). A MutableHeapNumber is not a HeapNumber.

Done. Good catch!

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/js-native-...
src/compiler/js-native-context-specialization.cc:2212:
simplified()->Allocate(Type::Internal(), NOT_TENURED),
On 2017/04/06 12:08:05, Benedikt Meurer wrote:
> Nit: Type::OtherInternal()

Done.

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
File src/compiler/simplified-operator.cc (right):

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
src/compiler/simplified-operator.cc:900: if (Type::Any()->Is(type)) {
On 2017/04/06 12:08:05, Benedikt Meurer wrote:
> I'd rather remove the caching completely. We don't allocate a lot of Allocator
> operators usually.

Done.

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
File src/compiler/simplified-operator.h (right):

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
src/compiler/simplified-operator.h:248: struct AllocationParameters {
On 2017/04/06 12:08:05, Benedikt Meurer wrote:
> Nit: AllocateParameters

Done.

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
src/compiler/simplified-operator.h:249: Type* type;
On 2017/04/06 12:08:05, Benedikt Meurer wrote:
> Can we please stick to classes here?

Done.

Out of curiosity, what is the rationale behind using classes for such simple
data structures? (I think even the style guide allows using structs.)

[commit-bot: I haz the power, 2017-04-06 15:59:21]

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

[commit-bot: I haz the power, 2017-04-06 15:59:21]

Dry run: This issue passed the CQ dry run.

[Benedikt Meurer, 2017-04-06 17:22:28]

THank you, LGTM!

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
File src/compiler/simplified-operator.h (right):

https://codereview.chromium.org/2797993006/diff/20001/src/compiler/simplified...
src/compiler/simplified-operator.h:249: Type* type;
On 2017/04/06 15:11:29, Jarin wrote:
> On 2017/04/06 12:08:05, Benedikt Meurer wrote:
> > Can we please stick to classes here?
> 
> Done.
> 
> Out of curiosity, what is the rationale behind using classes for such simple
> data structures? (I think even the style guide allows using structs.)

I'd like to have some consistency. Switching to structs should be done
consistently. What worries me about structs is the refactoring bugs in C++
because of magical self healing.

[Jarin, 2017-04-07 08:20:25]

The CQ bit was checked by jarin@chromium.org

[commit-bot: I haz the power, 2017-04-07 08:20:36]

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, 2017-04-07 08:32:16]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1491553225105980,
"parent_rev": "fae3f6bf4476b80b6f02167c51cacea57420cb1a", "commit_rev":
"e97b29a4c5741f11318416877fc43c3c8cea93a2"}

[commit-bot: I haz the power, 2017-04-07 08:32:22]

Description was changed from

==========
[turbofan] Add type to the allocation operator.

This gives us more precise type information, so we can avoid some type
guards to refine the type information back.

The motivation for this is to help escape analysis by not introducing
redundant type guards (which escape analysis cannot handle yet even
though it could and should do).

Motivating example:

In the example below, the out-of-object property array for properties
fld5 and fld6 gets type Any when it is created by "o.fld5 = 5" (for
object literals, we store 4 properties in-objeca, the rest goes out
of object).

When we run load elimination for the load the out-of-object property
array (to store 6 into o.fld6), load elimination inserts TypeGuard to
enforce the Type::Internal() type. This makes escape analysis bail out
on this object, and we do not eliminate the object creation.

function f() {
  var o = {};
  o.fld1 = 1;
  o.fld2 = 2;
  o.fld3 = 3;
  o.fld4 = 4;
  o.fld5 = 5;
  o.fld6 = 6;
}

f();
f();
%OptimizeFunctionOnNextCall(f);
f();
==========

to

==========
[turbofan] Add type to the allocation operator.

This gives us more precise type information, so we can avoid some type
guards to refine the type information back.

The motivation for this is to help escape analysis by not introducing
redundant type guards (which escape analysis cannot handle yet even
though it could and should do).

Motivating example:

In the example below, the out-of-object property array for properties
fld5 and fld6 gets type Any when it is created by "o.fld5 = 5" (for
object literals, we store 4 properties in-objeca, the rest goes out
of object).

When we run load elimination for the load the out-of-object property
array (to store 6 into o.fld6), load elimination inserts TypeGuard to
enforce the Type::Internal() type. This makes escape analysis bail out
on this object, and we do not eliminate the object creation.

function f() {
  var o = {};
  o.fld1 = 1;
  o.fld2 = 2;
  o.fld3 = 3;
  o.fld4 = 4;
  o.fld5 = 5;
  o.fld6 = 6;
}

f();
f();
%OptimizeFunctionOnNextCall(f);
f();

Review-Url: https://codereview.chromium.org/2797993006
Cr-Commit-Position: refs/heads/master@{#44470}
Committed:
https://chromium.googlesource.com/v8/v8/+/e97b29a4c5741f11318416877fc43c3c8ce...
==========

[commit-bot: I haz the power, 2017-04-07 08:32:23]

Committed patchset #4 (id:60001) as
https://chromium.googlesource.com/v8/v8/+/e97b29a4c5741f11318416877fc43c3c8ce...