Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2537103002:
[Compiler] Don't mark asm-wasm functions for optimization in PostInstantiation. (Closed)
Description[Compiler] Don't mark asm-wasm functions for optimization in PostInstantiation.
Functions with asm-wasm data shouldn't be marked for optimization, since
they will be optimized using the asm-wasm data instead.
Committed: https://crrev.com/f8b898396296ac5ef67b77b1001cb216ca6f8106
Cr-Commit-Position: refs/heads/master@{#41367}
Patch Set 1 #Patch Set 2 : Testing numbering #
Total comments: 2
Patch Set 3 : Add another fix #Patch Set 4 : Remove astnumbering changes #Messages
Total messages: 20 (13 generated)
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
rmcilroy@chromium.org changed reviewers: + bmeurer@chromium.org, jarin@chromium.org
This should hopefully fix the let/const and object literal via TF CLs. Testing now with the ast-numbering changes - if it works I'll remove those changes from this CL.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_presubmit on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/29584)
LGTM, thanks. Awesome. https://codereview.chromium.org/2537103002/diff/20001/src/ast/ast-numbering.cc File src/ast/ast-numbering.cc (right): https://codereview.chromium.org/2537103002/diff/20001/src/ast/ast-numbering.c... src/ast/ast-numbering.cc:161: if (IsLexicalVariableMode(node->var()->mode())) { Just remember to remove this prior to landing! :-) https://codereview.chromium.org/2537103002/diff/20001/src/ast/ast-numbering.c... src/ast/ast-numbering.cc:506: DisableFullCodegenAndCrankshaft(kClassLiteral); This too :-)
On 2016/11/29 12:43:17, Benedikt Meurer wrote: > LGTM, thanks. Awesome. > > https://codereview.chromium.org/2537103002/diff/20001/src/ast/ast-numbering.cc > File src/ast/ast-numbering.cc (right): > > https://codereview.chromium.org/2537103002/diff/20001/src/ast/ast-numbering.c... > src/ast/ast-numbering.cc:161: if (IsLexicalVariableMode(node->var()->mode())) { > Just remember to remove this prior to landing! :-) > > https://codereview.chromium.org/2537103002/diff/20001/src/ast/ast-numbering.c... > src/ast/ast-numbering.cc:506: DisableFullCodegenAndCrankshaft(kClassLiteral); > This too :-) Hmm, still seems to be some test failures for different reasons. I'll try to have a look.
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_presubmit on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/29611)
Added one other fix for EnsureBytecode which fixes all DCHECKS in compiler.cc, however there are still two tests failing (regress-105 and regress-612412) with the object literals via turbofan. It only seems to fail with --stress-opt (which I don't think we test on pure turbo) so could these be real Turbofan bugs? Landing the other two fixes in any case.
The CQ bit was checked by rmcilroy@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org Link to the patchset: https://codereview.chromium.org/2537103002/#ps60001 (title: "Remove astnumbering changes")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 60001, "attempt_start_ts": 1480436236005210,
"parent_rev": "e6abb94016d81a6ca382dd665cb7e20e305e4219", "commit_rev":
"0db306a536490f9ad3b82702cf7e6e3028e28936"}
Message was sent while issue was closed.
Committed patchset #4 (id:60001)
Message was sent while issue was closed.
Description was changed from ========== [Compiler] Don't mark asm-wasm functions for optimization in PostInstantiation. Functions with asm-wasm data shouldn't be marked for optimization, since they will be optimized using the asm-wasm data instead. ========== to ========== [Compiler] Don't mark asm-wasm functions for optimization in PostInstantiation. Functions with asm-wasm data shouldn't be marked for optimization, since they will be optimized using the asm-wasm data instead. Committed: https://crrev.com/f8b898396296ac5ef67b77b1001cb216ca6f8106 Cr-Commit-Position: refs/heads/master@{#41367} ==========
Message was sent while issue was closed.
Patchset 4 (id:??) landed as https://crrev.com/f8b898396296ac5ef67b77b1001cb216ca6f8106 Cr-Commit-Position: refs/heads/master@{#41367} |
