Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1994223002:
[Compiler] Skip Ignition for asm.js code. (Closed)
Description[Compiler] Skip Ignition for asm.js code.
Since we can't OSR from an function compiled with Ignition, this makes it
impossible to tier up asm.js code as it is running. As such, this CL
bypasses Ignition for asm.js code.
BUG=v8:4280
LOG=N
Committed: https://crrev.com/9be961f59b911de8f8c3bad13e0235c27da05423
Cr-Commit-Position: refs/heads/master@{#36483}
Patch Set 1 : #
Total comments: 1
Patch Set 2 : Revert GetEagerCode from this CL #
Total comments: 11
Patch Set 3 : Feedback #Patch Set 4 : Move marking in PostInstantiation after optimizied code map check. #Patch Set 5 : Disable sqlite3 tests on debug #Patch Set 6 : Ignition only for now #Patch Set 7 : Skip Ignition but don't go straight to TF #Messages
Total messages: 43 (18 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/patch-status/1994223002/1 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1994223002/1
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/patch-status/1994223002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1994223002/20001
Patchset #1 (id:1) has been deleted
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_avx2_rel_ng on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...) v8_linux64_avx2_rel_ng_triggered on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...)
rmcilroy@chromium.org changed reviewers: + mstarzinger@chromium.org
Michi - still WIP. This change causes a massive improvement in Jetstream ASM.js tests with Ignition (and doesn't regress those tests in non-Ignition). However, the sqlite mjsunit tests now take a massive amount longer than before I'm not sure if there is something special about the sqlite tests causing this, or if TurboFan just needs the type feedback for certain asmjs patterns to perform good optimization (I didn't think we used type feedback for AsmJS in TF - am I wrong?). If it's the latter, then we will probably need to change this to just skip Ignition and go to FCG rather than trying to optimize to TF directly. https://codereview.chromium.org/1994223002/diff/20001/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/1994223002/diff/20001/src/compiler.cc#newcode993 src/compiler.cc:993: bool GetEagerCode(CompilationInfo* info) { I factored this code out of NewSharedFunctionInfoForLiteral when I was thinking about doing this a different way. I ended up not needing to do this, and the code here is practically the same as was in NewSharedFunctionInfoForLiteral, but I think it is clearer as a seperate function like this. WDYT? Happy to remove this part of the change if you don't like it.
https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode946 src/compiler.cc:946: (FLAG_turbo_asm_deoptimization || !isolate->debug()->is_active()); What would you thing about guarding this by FLAG_ignition as well. Because for the shipping configuration (with OSR support) we abandoned the eager optimization of asm.js functions. https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode981 src/compiler.cc:981: if (FLAG_always_opt || ShouldOptimizeForAsm(isolate, function)) { Can we keep the optimization path for production above the unoptimized compile? That way we don't needlessly compile unoptimized code without deoptimization support. For the --always-opt case the trigger is down here to increase code coverage. https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode... src/compiler.cc:1777: if ((FLAG_always_opt || ShouldOptimizeForAsm(isolate, function)) && I am not entirely sure why this is needed. For functions where SFI is not yet compiled we should hit the GetLazy code path above. For functions where SFI is already compiled, the optimized code map should hit. Could you elaborate in this?
https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode946 src/compiler.cc:946: (FLAG_turbo_asm_deoptimization || !isolate->debug()->is_active()); On 2016/05/20 11:45:10, Michael Starzinger wrote: > What would you thing about guarding this by FLAG_ignition as well. Because for > the shipping configuration (with OSR support) we abandoned the eager > optimization of asm.js functions. Is there any particularly reason we abandoned it? Given asmJS is meant to be ahead-of-time style code isn't it better just to optimize first without running unoptimized code at all (and possibly causing jank mid-way through the app when we recompile for OSR)? As I mentioned on the chat, there is an issue with the sqlite tests which are much slower after this change. Is there type feedback you are relying on in TF to optmize asmJS code? If so, we should probably just skip Ignition and go straight to FCG here rather than trying to optimize straight to TF. https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode981 src/compiler.cc:981: if (FLAG_always_opt || ShouldOptimizeForAsm(isolate, function)) { On 2016/05/20 11:45:10, Michael Starzinger wrote: > Can we keep the optimization path for production above the unoptimized compile? > That way we don't needlessly compile unoptimized code without deoptimization > support. For the --always-opt case the trigger is down here to increase code > coverage. Done. https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode... src/compiler.cc:1777: if ((FLAG_always_opt || ShouldOptimizeForAsm(isolate, function)) && On 2016/05/20 11:45:10, Michael Starzinger wrote: > I am not entirely sure why this is needed. For functions where SFI is not yet > compiled we should hit the GetLazy code path above. For functions where SFI is > already compiled, the optimized code map should hit. Could you elaborate in > this? This is for the eager compilation pipeline (--ignition-eager) without it we don't optimize on first-run (there is nothing in the optimized code map the first time we run) and so we run the unoptimized bytecode.
https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode... src/compiler.cc:1777: if ((FLAG_always_opt || ShouldOptimizeForAsm(isolate, function)) && On 2016/05/20 12:42:03, rmcilroy wrote: > On 2016/05/20 11:45:10, Michael Starzinger wrote: > > I am not entirely sure why this is needed. For functions where SFI is not yet > > compiled we should hit the GetLazy code path above. For functions where SFI is > > already compiled, the optimized code map should hit. Could you elaborate in > > this? > > This is for the eager compilation pipeline (--ignition-eager) without it we > don't optimize on first-run (there is nothing in the optimized code map the > first time we run) and so we run the unoptimized bytecode. I just realized, this would mark all new functions for optimization even if there was something already in the code cache (I mistakenly thought --always-opt would do the right thing but forgot it was a purely testing flag). I've moved this down to below the optimized code map check. I still have issues with sqlite timing out though :/.
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/patch-status/1994223002/120001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1994223002/120001
Patchset #5 (id:100001) has been deleted
mstarzinger@chromium.org changed reviewers: + bmeurer@chromium.org, titzer@chromium.org
LGTM with one comment to address as discussed offline. https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode946 src/compiler.cc:946: (FLAG_turbo_asm_deoptimization || !isolate->debug()->is_active()); On 2016/05/20 12:42:03, rmcilroy wrote: > On 2016/05/20 11:45:10, Michael Starzinger wrote: > > What would you thing about guarding this by FLAG_ignition as well. Because for > > the shipping configuration (with OSR support) we abandoned the eager > > optimization of asm.js functions. > > Is there any particularly reason we abandoned it? Given asmJS is meant to be > ahead-of-time style code isn't it better just to optimize first without running > unoptimized code at all (and possibly causing jank mid-way through the app when > we recompile for OSR)? > > As I mentioned on the chat, there is an issue with the sqlite tests which are > much slower after this change. Is there type feedback you are relying on in TF > to optmize asmJS code? If so, we should probably just skip Ignition and go > straight to FCG here rather than trying to optimize straight to TF. As discussed offline: I am afraid this will tank our shipping configuration. If we want to change the shipping configuration then I would vote for doing so in a separate CL (i.e. land this CL with the additional check for FLAG_ignition, then land a second CL that removes the FLAG_ignition). This way we can at least revert it easily without having the remove the Ignition path. +Benedikt, +Ben: WDYT? https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode... src/compiler.cc:1777: if ((FLAG_always_opt || ShouldOptimizeForAsm(isolate, function)) && On 2016/05/23 09:28:16, rmcilroy wrote: > On 2016/05/20 12:42:03, rmcilroy wrote: > > On 2016/05/20 11:45:10, Michael Starzinger wrote: > > > I am not entirely sure why this is needed. For functions where SFI is not > yet > > > compiled we should hit the GetLazy code path above. For functions where SFI > is > > > already compiled, the optimized code map should hit. Could you elaborate in > > > this? > > > > This is for the eager compilation pipeline (--ignition-eager) without it we > > don't optimize on first-run (there is nothing in the optimized code map the > > first time we run) and so we run the unoptimized bytecode. > > I just realized, this would mark all new functions for optimization even if > there was something already in the code cache (I mistakenly thought --always-opt > would do the right thing but forgot it was a purely testing flag). I've moved > this down to below the optimized code map check. I still have issues with sqlite > timing out though :/. Acknowledged. New version in patch set #5 works for me.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode946 src/compiler.cc:946: (FLAG_turbo_asm_deoptimization || !isolate->debug()->is_active()); On 2016/05/23 14:45:38, Michael Starzinger wrote: > On 2016/05/20 12:42:03, rmcilroy wrote: > > On 2016/05/20 11:45:10, Michael Starzinger wrote: > > > What would you thing about guarding this by FLAG_ignition as well. Because > for > > > the shipping configuration (with OSR support) we abandoned the eager > > > optimization of asm.js functions. > > > > Is there any particularly reason we abandoned it? Given asmJS is meant to be > > ahead-of-time style code isn't it better just to optimize first without > running > > unoptimized code at all (and possibly causing jank mid-way through the app > when > > we recompile for OSR)? > > > > As I mentioned on the chat, there is an issue with the sqlite tests which are > > much slower after this change. Is there type feedback you are relying on in TF > > to optmize asmJS code? If so, we should probably just skip Ignition and go > > straight to FCG here rather than trying to optimize straight to TF. > > As discussed offline: I am afraid this will tank our shipping configuration. If > we want to change the shipping configuration then I would vote for doing so in a > separate CL (i.e. land this CL with the additional check for FLAG_ignition, then > land a second CL that removes the FLAG_ignition). This way we can at least > revert it easily without having the remove the Ignition path. > > +Benedikt, +Ben: WDYT? Sounds good, I've updated this CL to only do this for FLAG_ignition and will upload another CL for the shipping configuration.
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/patch-status/1994223002/140001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1994223002/140001
Description was changed from ========== [Compiler] Always compile asm.js code with TurboFan where possible. For asm.js code, when possible try to compile and run with TurboFan initially, bypassing unoptimized code. This has a big impact on Ignition due to the lack of OSR support in Ignition. BUG=v8:4280 LOG=N ========== to ========== [Compiler] Always compile asm.js code with TurboFan when Ignition is enabled. For asm.js code, when Ignition is enabled, always try to compile and run with TurboFan initially, bypassing unoptimized code. This has a big impact on Ignition due to the lack of OSR support in Ignition. BUG=v8:4280 LOG=N ==========
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode946 src/compiler.cc:946: (FLAG_turbo_asm_deoptimization || !isolate->debug()->is_active()); On 2016/05/20 12:42:03, rmcilroy wrote: > On 2016/05/20 11:45:10, Michael Starzinger wrote: > > What would you thing about guarding this by FLAG_ignition as well. Because for > > the shipping configuration (with OSR support) we abandoned the eager > > optimization of asm.js functions. > > Is there any particularly reason we abandoned it? Given asmJS is meant to be > ahead-of-time style code isn't it better just to optimize first without running > unoptimized code at all (and possibly causing jank mid-way through the app when > we recompile for OSR)? > > As I mentioned on the chat, there is an issue with the sqlite tests which are > much slower after this change. Is there type feedback you are relying on in TF > to optmize asmJS code? If so, we should probably just skip Ignition and go > straight to FCG here rather than trying to optimize straight to TF. It's not type feedback, it's just that TF is too heavyweight for the startup phase of asm.js code. But OSR is required for the asm.js benchmarks to do well. So OSR from ignition->TF for asm.js code is probably not in the cards, so maybe best to just do as you say and do FCG.
On 2016/05/23 15:48:34, titzer wrote: > https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc > File src/compiler.cc (right): > > https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode946 > src/compiler.cc:946: (FLAG_turbo_asm_deoptimization || > !isolate->debug()->is_active()); > On 2016/05/20 12:42:03, rmcilroy wrote: > > On 2016/05/20 11:45:10, Michael Starzinger wrote: > > > What would you thing about guarding this by FLAG_ignition as well. Because > for > > > the shipping configuration (with OSR support) we abandoned the eager > > > optimization of asm.js functions. > > > > Is there any particularly reason we abandoned it? Given asmJS is meant to be > > ahead-of-time style code isn't it better just to optimize first without > running > > unoptimized code at all (and possibly causing jank mid-way through the app > when > > we recompile for OSR)? > > > > As I mentioned on the chat, there is an issue with the sqlite tests which are > > much slower after this change. Is there type feedback you are relying on in TF > > to optmize asmJS code? If so, we should probably just skip Ignition and go > > straight to FCG here rather than trying to optimize straight to TF. > > It's not type feedback, it's just that TF is too heavyweight for the startup > phase of asm.js code. But OSR is required for the asm.js benchmarks to do well. > So OSR from ignition->TF for asm.js code is probably not in the cards, so maybe > best to just do as you say and do FCG. Yeah I realize the regression in the sqlite test was TF startup (only for debug builds) after some debugging. As for TF being too heavyweight for startup of asm.js code - do you have any examples of benchmarks which exhibit this? The asm.js benchmarks in Jetstream all seem to quite like this change AFAIKT.
On 2016/05/23 16:08:29, rmcilroy wrote: > On 2016/05/23 15:48:34, titzer wrote: > > https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc > > File src/compiler.cc (right): > > > > > https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode946 > > src/compiler.cc:946: (FLAG_turbo_asm_deoptimization || > > !isolate->debug()->is_active()); > > On 2016/05/20 12:42:03, rmcilroy wrote: > > > On 2016/05/20 11:45:10, Michael Starzinger wrote: > > > > What would you thing about guarding this by FLAG_ignition as well. Because > > for > > > > the shipping configuration (with OSR support) we abandoned the eager > > > > optimization of asm.js functions. > > > > > > Is there any particularly reason we abandoned it? Given asmJS is meant to be > > > ahead-of-time style code isn't it better just to optimize first without > > running > > > unoptimized code at all (and possibly causing jank mid-way through the app > > when > > > we recompile for OSR)? > > > > > > As I mentioned on the chat, there is an issue with the sqlite tests which > are > > > much slower after this change. Is there type feedback you are relying on in > TF > > > to optmize asmJS code? If so, we should probably just skip Ignition and go > > > straight to FCG here rather than trying to optimize straight to TF. > > > > It's not type feedback, it's just that TF is too heavyweight for the startup > > phase of asm.js code. But OSR is required for the asm.js benchmarks to do > well. > > So OSR from ignition->TF for asm.js code is probably not in the cards, so > maybe > > best to just do as you say and do FCG. > > Yeah I realize the regression in the sqlite test was TF startup (only for debug > builds) after some debugging. > > As for TF being too heavyweight for startup of asm.js code - do you have any > examples of benchmarks which exhibit this? The asm.js benchmarks in Jetstream > all seem to quite like this change AFAIKT. We saw this on the UE4 engine startup and on Dead Trigger 2.
On 2016/05/23 16:18:34, titzer wrote: > On 2016/05/23 16:08:29, rmcilroy wrote: > > On 2016/05/23 15:48:34, titzer wrote: > > > https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc > > > File src/compiler.cc (right): > > > > > > > > > https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode946 > > > src/compiler.cc:946: (FLAG_turbo_asm_deoptimization || > > > !isolate->debug()->is_active()); > > > On 2016/05/20 12:42:03, rmcilroy wrote: > > > > On 2016/05/20 11:45:10, Michael Starzinger wrote: > > > > > What would you thing about guarding this by FLAG_ignition as well. > Because > > > for > > > > > the shipping configuration (with OSR support) we abandoned the eager > > > > > optimization of asm.js functions. > > > > > > > > Is there any particularly reason we abandoned it? Given asmJS is meant to > be > > > > ahead-of-time style code isn't it better just to optimize first without > > > running > > > > unoptimized code at all (and possibly causing jank mid-way through the app > > > when > > > > we recompile for OSR)? > > > > > > > > As I mentioned on the chat, there is an issue with the sqlite tests which > > are > > > > much slower after this change. Is there type feedback you are relying on > in > > TF > > > > to optmize asmJS code? If so, we should probably just skip Ignition and go > > > > straight to FCG here rather than trying to optimize straight to TF. > > > > > > It's not type feedback, it's just that TF is too heavyweight for the startup > > > phase of asm.js code. But OSR is required for the asm.js benchmarks to do > > well. > > > So OSR from ignition->TF for asm.js code is probably not in the cards, so > > maybe > > > best to just do as you say and do FCG. > > > > Yeah I realize the regression in the sqlite test was TF startup (only for > debug > > builds) after some debugging. > > > > As for TF being too heavyweight for startup of asm.js code - do you have any > > examples of benchmarks which exhibit this? The asm.js benchmarks in Jetstream > > all seem to quite like this change AFAIKT. > > We saw this on the UE4 engine startup and on Dead Trigger 2. Yes you're right, for a rough look at a stopwatch running Dead Trigger 2 it seems to launch in about half the time without this change in the non-Ignition pipeline. I think you are right, the best approach is probably just to skip Ignition and go straight to FCG rather than direct to TF. Michi - if you are happy with this approach I'll update the CL to make this change tomorrow.
On 2016/05/23 16:34:22, rmcilroy wrote: > On 2016/05/23 16:18:34, titzer wrote: > > On 2016/05/23 16:08:29, rmcilroy wrote: > > > On 2016/05/23 15:48:34, titzer wrote: > > > > https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc > > > > File src/compiler.cc (right): > > > > > > > > > > > > > > https://codereview.chromium.org/1994223002/diff/40001/src/compiler.cc#newcode946 > > > > src/compiler.cc:946: (FLAG_turbo_asm_deoptimization || > > > > !isolate->debug()->is_active()); > > > > On 2016/05/20 12:42:03, rmcilroy wrote: > > > > > On 2016/05/20 11:45:10, Michael Starzinger wrote: > > > > > > What would you thing about guarding this by FLAG_ignition as well. > > Because > > > > for > > > > > > the shipping configuration (with OSR support) we abandoned the eager > > > > > > optimization of asm.js functions. > > > > > > > > > > Is there any particularly reason we abandoned it? Given asmJS is meant > to > > be > > > > > ahead-of-time style code isn't it better just to optimize first without > > > > running > > > > > unoptimized code at all (and possibly causing jank mid-way through the > app > > > > when > > > > > we recompile for OSR)? > > > > > > > > > > As I mentioned on the chat, there is an issue with the sqlite tests > which > > > are > > > > > much slower after this change. Is there type feedback you are relying on > > in > > > TF > > > > > to optmize asmJS code? If so, we should probably just skip Ignition and > go > > > > > straight to FCG here rather than trying to optimize straight to TF. > > > > > > > > It's not type feedback, it's just that TF is too heavyweight for the > startup > > > > phase of asm.js code. But OSR is required for the asm.js benchmarks to do > > > well. > > > > So OSR from ignition->TF for asm.js code is probably not in the cards, so > > > maybe > > > > best to just do as you say and do FCG. > > > > > > Yeah I realize the regression in the sqlite test was TF startup (only for > > debug > > > builds) after some debugging. > > > > > > As for TF being too heavyweight for startup of asm.js code - do you have any > > > examples of benchmarks which exhibit this? The asm.js benchmarks in > Jetstream > > > all seem to quite like this change AFAIKT. > > > > We saw this on the UE4 engine startup and on Dead Trigger 2. > > Yes you're right, for a rough look at a stopwatch running Dead Trigger 2 it > seems to launch in about half the time without this change in the non-Ignition > pipeline. > > I think you are right, the best approach is probably just to skip Ignition and > go straight to FCG rather than direct to TF. > > Michi - if you are happy with this approach I'll update the CL to make this > change tomorrow. So to rephrase, just to ensure I am understanding you correct: You are proposing to not add the path directly to TF (current state of this CL), but instead just disable Ignition for asm.js code and go to FCG directly. Correct? Works for me. Could we do this directly in the UseIgnition predicate then? That avoids adding this new path and instead takes an existing (and hopefully well-tested) path.
> So to rephrase, just to ensure I am understanding you correct: You are proposing > to not add the path directly to TF (current state of this CL), but instead just > disable Ignition for asm.js code and go to FCG directly. Correct? Works for me. > Could we do this directly in the UseIgnition predicate then? That avoids adding > this new path and instead takes an existing (and hopefully well-tested) path. Yes exactly. Good idea using the UseIgnition predicate. Done, PTAL, thanks.
Description was changed from ========== [Compiler] Always compile asm.js code with TurboFan when Ignition is enabled. For asm.js code, when Ignition is enabled, always try to compile and run with TurboFan initially, bypassing unoptimized code. This has a big impact on Ignition due to the lack of OSR support in Ignition. BUG=v8:4280 LOG=N ========== to ========== [Compiler] Skip Ignition for asm.js code. Since we can't OSR from an function compiled with Ignition, this makes it impossible to tier up asm.js code as it is running. As such, this CL bypasses Ignition for asm.js code. BUG=v8:4280 LOG=N ==========
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/patch-status/1994223002/160001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1994223002/160001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Yep. Still LGTM. I like this much more, less paths to worry about.
The CQ bit was checked by rmcilroy@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1994223002/160001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1994223002/160001
Message was sent while issue was closed.
Description was changed from ========== [Compiler] Skip Ignition for asm.js code. Since we can't OSR from an function compiled with Ignition, this makes it impossible to tier up asm.js code as it is running. As such, this CL bypasses Ignition for asm.js code. BUG=v8:4280 LOG=N ========== to ========== [Compiler] Skip Ignition for asm.js code. Since we can't OSR from an function compiled with Ignition, this makes it impossible to tier up asm.js code as it is running. As such, this CL bypasses Ignition for asm.js code. BUG=v8:4280 LOG=N ==========
Message was sent while issue was closed.
Committed patchset #7 (id:160001)
Message was sent while issue was closed.
Description was changed from ========== [Compiler] Skip Ignition for asm.js code. Since we can't OSR from an function compiled with Ignition, this makes it impossible to tier up asm.js code as it is running. As such, this CL bypasses Ignition for asm.js code. BUG=v8:4280 LOG=N ========== to ========== [Compiler] Skip Ignition for asm.js code. Since we can't OSR from an function compiled with Ignition, this makes it impossible to tier up asm.js code as it is running. As such, this CL bypasses Ignition for asm.js code. BUG=v8:4280 LOG=N Committed: https://crrev.com/9be961f59b911de8f8c3bad13e0235c27da05423 Cr-Commit-Position: refs/heads/master@{#36483} ==========
Message was sent while issue was closed.
Patchset 7 (id:??) landed as https://crrev.com/9be961f59b911de8f8c3bad13e0235c27da05423 Cr-Commit-Position: refs/heads/master@{#36483} |
