deps: cherry-pick 7c982e7 from V8 upstream

[jbajwa]

Original commit message:

PPC/s390: [Turbofan]: Use new MachineTypes in access-builder.

Port 56429fc14671a10749190a4dfeacd38b7270f6f5

Original Commit Message:

    Introduced MachineType::TaggedSigned() and TaggedPointer().

    The idea is to quit using the representational dimension of Type, and
    instead encode this information in the MachineRepresentation (itself
    lightly wrapped in MachineType, along with MachineSemantic).

    There are three parts to the whole change:

    1) Places that set the machine representation - constant nodes, loads nad
       stores, global object and native context specialization.

    2) Places that propagate type/representation - this is representation
       inference (aka simplified lowering). At the end of this process we
       expect to have a MachineRepresentation for every node. An interesting
       part of this is phi merging.

    3) Places that examine representation - WriteBarrier elimination does this.
       Currently it's looking at the Type representation dimension, but as
       a part of this change (or in a soon-to-follow change) it can simply
       examine the MachineRepresentation.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2662223003
Cr-Commit-Position: refs/heads/master@{#42817}

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

V8

Description of change

This port is in V8 5.6/5.7 but couldn't make it to V8 5.5.
When node master moves to 5.6, it should have this commit, so only affects node version with V8 5.5

/cc @nodejs/v8

[mhdawson]

Node CI run: https://ci.nodejs.org/job/node-test-pull-request/6323/
V8 CI run: https://ci.nodejs.org/job/node-test-commit-v8-linux/563/

[bnoordhuis]

LGTM but out of curiosity, are the DCHECK_EQs in code-stub-assembler.cc and compiler/loop-variable-optimizer.cc still sound?

I see the same checks in V8 master so I assume the answer is 'yes' but I thought I'd ask anyway.

[jbajwa]

@bnoordhuis Yes, those checks should work for debug builds.
Also, the 1 test failure seems to be flaky as per #11029 (comment)

[ofrobots]

LGTM. Please squash at landing time.

[jbajwa]

I've squashed the commits, could someone help with landing this PR? I don't have write access. Thank you.
@nodejs/v8

[bnoordhuis]

@jbajwa Can you rebase? I'll rerun the CI and land it afterwards.

[jbajwa]

@bnoordhuis
I've rebased. Thanks!

[bnoordhuis]

Node CI: https://ci.nodejs.org/job/node-test-pull-request/6409/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/570/

Ping me if they're green and I'll land it.

[bnoordhuis]

@nodejs/build There's something wrong with the V8 ppc buildbots, they show the wrong commit...

https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=ppcbe-ubuntu1404,v8test=v8test/569/ - should be this PR, is something completely different. I think they simply never started.

[jbajwa]

@bnoordhuis
Looks like ppcbe/le buildbots are busy atm, the job for this PR should be in the queue.
https://ci.nodejs.org/computer/test-osuosl-ubuntu14-ppc64_le-1/
https://ci.nodejs.org/computer/test-osuosl-ubuntu14-ppc64_be-1/
Also the jenkins url you mentioned points to job 569, but for this PR its 570.

[bnoordhuis]

The ppc buildbot links on https://ci.nodejs.org/job/node-test-commit-v8-linux/570/ pointed to 569 but it looks like they've started now.

[jbajwa]

@bnoordhuis
Hi Ben, the CI run has completed and is green. Should be good to land. Thanks!

[bnoordhuis]

Oh, I hadn't realized this is against v7.x-staging. I wouldn't want to second-guess the releaser (I think it's @italoacasas this week?) so I'll defer to him on when to land it. This is good to go, though.

[italoacasas]

Landed fe99edd, thanks everyone.

[jasnell]

needs a backport if this needs to land on v6