deps: cherry-pick 7c982e7 from V8 upstream - #11263
Conversation
|
Node CI run: https://ci.nodejs.org/job/node-test-pull-request/6323/ |
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
|
@bnoordhuis Yes, those checks should work for debug builds. |
Sorry, something went wrong.
ofrobots
left a comment
There was a problem hiding this comment.
LGTM. Please squash at landing time.
Sorry, something went wrong.
|
I've squashed the commits, could someone help with landing this PR? I don't have write access. Thank you. |
Sorry, something went wrong.
|
@jbajwa Can you rebase? I'll rerun the CI and land it afterwards. |
Sorry, something went wrong.
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@{nodejs#42817}
|
Node CI: https://ci.nodejs.org/job/node-test-pull-request/6409/ Ping me if they're green and I'll land it. |
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
|
@bnoordhuis |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
@bnoordhuis |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
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}
PR-URL: #11263
Backport-of: v8/v8@7c982e7
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
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}
PR-URL: #11263
Backport-of: v8/v8@7c982e7
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
|
needs a backport if this needs to land on v6 |
Sorry, something went wrong.
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
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