- 12 Aug, 2016 1 commit
-
-
yangguo authored
Previously, we would both instrument the code, and add/remove BreakPointInfo objects through BreakLocation. This is bad design and unsuitable for having two different code kinds. We would now add/remove BreakPointInfo objects, and use that as source of truth when instrumenting the code. If we have both bytecode and FCG code, we would simply apply these break points twice to either. Notable changes: - Removed many functionality from BreakLocation. - Instrumentation (patching code for breaks) happens by applying break point info onto code. - Instrumentation (code patching) is done by the BreakIterator. For bytecode, it's BytecodeArrayBreakIterator. For FCG code, it's CodeBreakIterator. - Changes to code instrumentation mostly involves clearing current instrumentation and then (re-)applying break points. - DebugInfo can now reference both bytecode and FCG code. R=jgruber@chromium.org, mstarzinger@chromium.org BUG=v8:5265 Review-Url: https://codereview.chromium.org/2238893002 Cr-Commit-Position: refs/heads/master@{#38596}
-
- 11 Aug, 2016 1 commit
-
-
Alexander.Gilday2 authored
Migrate the platform StringToNumber builtin to TurboFan. BUG=v8:5049 Review-Url: https://codereview.chromium.org/2235983003 Cr-Commit-Position: refs/heads/master@{#38573}
-
- 09 Aug, 2016 1 commit
-
-
franzih authored
Drive-by fix: Use CodeStubAssembler::LoadNativeContext() BUG=chromium:608675 Review-Url: https://codereview.chromium.org/2227763003 Cr-Commit-Position: refs/heads/master@{#38501}
-
- 05 Aug, 2016 2 commits
-
-
machenbach authored
Revert of [Interpreter] Collect type feedback for 'new' in the bytecode handler (patchset #6 id:100001 of https://codereview.chromium.org/2190293003/ ) Reason for revert: [Sheriff] Fails on nosnap debug: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/8403 Original issue's description: > [Interpreter] Collect type feedback for 'new' in the bytecode handler > > Collect type feedback in the bytecode handler for 'new' bytecode. The > earlier cl (https://codereview.chromium.org/2153433002/) was reverted > because that implementation did not collect allocation site feedback. > This regressed delta blue by an order of magnitude. This implementation > includes collection of allocation site feedback. > > BUG=v8:4280, v8:4780 > LOG=N > > Committed: https://crrev.com/9d5e6129c4c7f9cbfe81a5fad2a470f219fe137c > Cr-Commit-Position: refs/heads/master@{#38364} TBR=bmeurer@chromium.org,rmcilroy@chromium.org,balazs.kilvady@imgtec.com,mythria@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280, v8:4780 Review-Url: https://codereview.chromium.org/2212343002 Cr-Commit-Position: refs/heads/master@{#38368}
-
mythria authored
Collect type feedback in the bytecode handler for 'new' bytecode. The earlier cl (https://codereview.chromium.org/2153433002/) was reverted because that implementation did not collect allocation site feedback. This regressed delta blue by an order of magnitude. This implementation includes collection of allocation site feedback. BUG=v8:4280, v8:4780 LOG=N Review-Url: https://codereview.chromium.org/2190293003 Cr-Commit-Position: refs/heads/master@{#38364}
-
- 26 Jul, 2016 3 commits
-
-
mstarzinger authored
Reland of [interpreter] Add explicit OSR polling bytecode. (patchset #1 id:1 of https://codereview.chromium.org/2184553003/ ) Reason for revert: Fix has been landed. Original issue's description: > Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ ) > > Reason for revert: > Bunch of breakages. Maybe bad interaction with https://chromium.googlesource.com/v8/v8/+/e520e5da5550f0d1a975e87d6e66a2edecbb0c8e ? > > E.g.: > https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607 > > Original issue's description: > > [interpreter] Add explicit OSR polling bytecode. > > > > This adds an explicit {OsrPoll} bytecode into every loop header which > > triggers on-stack replacement when armed. Note that each such bytecode > > stores the static loop depths as an operand, and hence can be armed for > > specific loop depths. > > > > This also adds builtin code that triggers OSR compilation and switches > > execution over to optimized code in case compilation succeeds. In case > > compilation fails, the bytecode dispatch just continues unhindered. > > > > R=rmcilroy@chromium.org > > TEST=mjsunit/ignition/osr-from-bytecode > > BUG=v8:4764 > > > > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458 > > Cr-Commit-Position: refs/heads/master@{#38043} > > TBR=rmcilroy@chromium.org,mstarzinger@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:4764 > > Committed: https://crrev.com/439aa2c6d708bfd95db725bd6f97c4c49bbc51fc > Cr-Commit-Position: refs/heads/master@{#38044} TBR=rmcilroy@chromium.org,machenbach@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2184713002 Cr-Commit-Position: refs/heads/master@{#38056}
-
machenbach authored
Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ ) Reason for revert: Bunch of breakages. Maybe bad interaction with https://chromium.googlesource.com/v8/v8/+/e520e5da5550f0d1a975e87d6e66a2edecbb0c8e ? E.g.: https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607 Original issue's description: > [interpreter] Add explicit OSR polling bytecode. > > This adds an explicit {OsrPoll} bytecode into every loop header which > triggers on-stack replacement when armed. Note that each such bytecode > stores the static loop depths as an operand, and hence can be armed for > specific loop depths. > > This also adds builtin code that triggers OSR compilation and switches > execution over to optimized code in case compilation succeeds. In case > compilation fails, the bytecode dispatch just continues unhindered. > > R=rmcilroy@chromium.org > TEST=mjsunit/ignition/osr-from-bytecode > BUG=v8:4764 > > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458 > Cr-Commit-Position: refs/heads/master@{#38043} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4764 Review-Url: https://codereview.chromium.org/2184553003 Cr-Commit-Position: refs/heads/master@{#38044}
-
mstarzinger authored
This adds an explicit {OsrPoll} bytecode into every loop header which triggers on-stack replacement when armed. Note that each such bytecode stores the static loop depths as an operand, and hence can be armed for specific loop depths. This also adds builtin code that triggers OSR compilation and switches execution over to optimized code in case compilation succeeds. In case compilation fails, the bytecode dispatch just continues unhindered. R=rmcilroy@chromium.org TEST=mjsunit/ignition/osr-from-bytecode BUG=v8:4764 Review-Url: https://codereview.chromium.org/2172233002 Cr-Commit-Position: refs/heads/master@{#38043}
-
- 21 Jul, 2016 1 commit
-
-
ahaas authored
Original message: Calling Runtime::kAbort through a builtin instead of the c-entry stub will allow to generate the call in a background thread, because a builtin provides its own handle, whereas a code stub does not. @v8-mips-ports: Could you take a special look at the padding that is done in MacroAssembler::Abort()? Reason for revert: The reason for reverting is: Blocks roll: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/1622 The problem was that on arm64 the builtin for Abort() contained a call to Abort(). The problem is fixed by using a NoUseRealAbortsScope in the code generation of Abort(). R=titzer@chromium.org, rmcilroy@chromium.org, rodolph.perfetta@arm.com Review-Url: https://codereview.chromium.org/2163263002 Cr-Commit-Position: refs/heads/master@{#37929}
-
- 20 Jul, 2016 1 commit
-
-
hablich authored
Revert of [builtins] Introduce a builtin for Abort(). (patchset #5 id:80001 of https://codereview.chromium.org/2156923002/ ) Reason for revert: Blocks roll: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/1622 Original issue's description: > [builtins] Introduce a builtin for Abort(). > > Calling Runtime::kAbort through a builtin instead of the c-entry stub > will allow to generate the call in a background thread, because a > builtin provides its own handle, whereas a code stub does not. > > @v8-mips-ports: Could you take a special look at the padding that is > done in MacroAssembler::Abort()? > > R=bmeurer@chromium.org, titzer@chromium.org, mstarzinger@chromium.org, v8-mips-ports@googlegroups.com, v8-arm-ports@googlegroups.com > > Committed: https://crrev.com/9be015a254cfff871c56cd129523a729637e9158 > Cr-Commit-Position: refs/heads/master@{#37854} TBR=bmeurer@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,akos.palfi@imgtec.com,ahaas@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2163603003 Cr-Commit-Position: refs/heads/master@{#37883}
-
- 19 Jul, 2016 3 commits
-
-
mythria authored
Revert of [Interpreter] Collect type feedback for 'new' in the bytecode handler (patchset #6 id:100001 of https://codereview.chromium.org/2153433002/ ) Reason for revert: This cl causes a large regression in octane (https://chromeperf.appspot.com/group_report?bug_id=629503). I have to investigate the reason before I can reland this. Original issue's description: > [Interpreter] Collect type feedback for 'new' in the bytecode handler > > Collect type feedback in the bytecode handler for 'new' bytecode. The > current implementation does not collect allocation site feedback. > > BUG=v8:4280, v8:4780 > LOG=N > > Committed: https://crrev.com/1eadc76419b323fb2e55ae9953142f801704aa59 > Cr-Commit-Position: refs/heads/master@{#37862} TBR=rmcilroy@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280, v8:4780 Review-Url: https://codereview.chromium.org/2165633003 Cr-Commit-Position: refs/heads/master@{#37872}
-
mythria authored
Collect type feedback in the bytecode handler for 'new' bytecode. The current implementation does not collect allocation site feedback. BUG=v8:4280, v8:4780 LOG=N Review-Url: https://codereview.chromium.org/2153433002 Cr-Commit-Position: refs/heads/master@{#37862}
-
ahaas authored
Calling Runtime::kAbort through a builtin instead of the c-entry stub will allow to generate the call in a background thread, because a builtin provides its own handle, whereas a code stub does not. @v8-mips-ports: Could you take a special look at the padding that is done in MacroAssembler::Abort()? R=bmeurer@chromium.org, titzer@chromium.org, mstarzinger@chromium.org, v8-mips-ports@googlegroups.com, v8-arm-ports@googlegroups.com Review-Url: https://codereview.chromium.org/2156923002 Cr-Commit-Position: refs/heads/master@{#37854}
-
- 18 Jul, 2016 1 commit
-
-
yangguo authored
R=bmeurer@chromium.org BUG=v8:5197 Review-Url: https://codereview.chromium.org/2155633002 Cr-Commit-Position: refs/heads/master@{#37820}
-
- 15 Jul, 2016 1 commit
-
-
bmeurer authored
Migrate the platform NonNumberToNumber builtin to TurboFan, and change it to use the new NonPrimitiveToPrimitive builtin for the JSReceiver case. R=yangguo@chromium.org BUG=v8:5049 Review-Url: https://codereview.chromium.org/2153053002 Cr-Commit-Position: refs/heads/master@{#37786}
-
- 14 Jul, 2016 2 commits
-
-
mvstanton authored
This fix was made to address a performance issue in memory.long_running_idle_gmail_tbmv2, but it didn't improve things. BUG=615831 Review-Url: https://codereview.chromium.org/2144183002 Cr-Commit-Position: refs/heads/master@{#37746}
-
yangguo authored
R=bmeurer@chromium.org BUG=v8:5197 Review-Url: https://codereview.chromium.org/2145023002 Cr-Commit-Position: refs/heads/master@{#37740}
-
- 13 Jul, 2016 1 commit
-
-
mythria authored
Collect type feedback in the call bytecode handler. The current implementation only collects feedback for JS function objects. The other objects and Array functions do not collect any feedback. They will be marked Megamorphic. BUG=v8:4280, v8:4780 LOG=N Review-Url: https://codereview.chromium.org/2122183002 Cr-Commit-Position: refs/heads/master@{#37700}
-
- 08 Jul, 2016 1 commit
-
-
jgruber authored
BUG=v8:5173 R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2118283003 Cr-Commit-Position: refs/heads/master@{#37598}
-
- 04 Jul, 2016 1 commit
-
-
jgruber authored
Stack trace generation requires access to the receiver; and while the receiver is already on the stack, we cannot determine its position during stack trace generation (it's stored in argv[0], and argc is only stored in a callee-saved register). This patch grants access to the receiver by pushing argc onto builtin exit frames as an extra argument. Compared to simply pushing the receiver, this requires an additional dereference during stack trace generation, but one fewer during builtin calls. BUG=v8:4815 Review-Url: https://codereview.chromium.org/2106883003 Cr-Commit-Position: refs/heads/master@{#37500}
-
- 01 Jul, 2016 2 commits
-
-
jgruber authored
Both of these were broken in different ways: * On arm, the loop counter was passed as argc on the stack. * On arm64, we passed argc + 1 instead of argc. The result in both cases was an incorrect receiver for the builtin frame when generating stack traces. BUG=v8:4815 R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2112883002 Cr-Commit-Position: refs/heads/master@{#37471}
-
bradnelson authored
Directs 'use asm' traffic through asm-wasm conversion when --validate-asm is passed. Adds a builtin that handles the fallback to JS. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203 TEST=asm-wasm R=mstarzinger@chromium.org,titzer@chromium.org LOG=N Review-Url: https://codereview.chromium.org/2057403003 Cr-Commit-Position: refs/heads/master@{#37470}
-
- 30 Jun, 2016 1 commit
-
-
jgruber authored
Prior to this commit, calls to C++ builtins created standard exit frames, which are skipped when constructing JS stack traces. In order to show these calls on traces, we introduce a new builtin exit frame type. Builtin exit frames contain target and new.target on the stack and are not skipped during stack trace construction. BUG=v8:4815 R=bmeurer@chromium.org, yangguo@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a Review-Url: https://codereview.chromium.org/2090723005 Cr-Original-Commit-Position: refs/heads/master@{#37384} Cr-Commit-Position: refs/heads/master@{#37416}
-
- 29 Jun, 2016 2 commits
-
-
bmeurer authored
Revert of [builtins] New frame type for exits to C++ builtins (patchset #5 id:80001 of https://codereview.chromium.org/2090723005/ ) Reason for revert: Looks like this breaks on nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/7626 Original issue's description: > [builtins] New frame type for exits to C++ builtins > > Prior to this commit, calls to C++ builtins created standard exit > frames, which are skipped when constructing JS stack traces. In order to > show these calls on traces, we introduce a new builtin exit frame type. > > Builtin exit frames contain target and new.target on the stack and are > not skipped during stack trace construction. > > BUG=v8:4815 > R=bmeurer@chromium.org, yangguo@chromium.org > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel > > Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a > Cr-Commit-Position: refs/heads/master@{#37384} TBR=yangguo@chromium.org,jgruber@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4815 Review-Url: https://codereview.chromium.org/2106113002 Cr-Commit-Position: refs/heads/master@{#37394}
-
jgruber authored
Prior to this commit, calls to C++ builtins created standard exit frames, which are skipped when constructing JS stack traces. In order to show these calls on traces, we introduce a new builtin exit frame type. Builtin exit frames contain target and new.target on the stack and are not skipped during stack trace construction. BUG=v8:4815 R=bmeurer@chromium.org, yangguo@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel Review-Url: https://codereview.chromium.org/2090723005 Cr-Commit-Position: refs/heads/master@{#37384}
-
- 21 Jun, 2016 2 commits
-
-
neis authored
This runtime function now also works for Ignition generators. It returns the source position of the yield at which a suspended generator got suspended. This works by storing the current bytecode offset at suspension and using an existing mechanism to map it back to a source position. TBR=littledan@chromium.org BUG= Review-Url: https://codereview.chromium.org/2079613003 Cr-Commit-Position: refs/heads/master@{#37140}
-
ahaas authored
With the tail call, pointers to the JS heap could be pushed on a js-to-wasm frame. On the js-to-wasm frame, however, this pointer would not be updated by the GC. R=bmeurer@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com BUG=617084 TEST=mjsunit/wasm/gc-frame.js:GCInJSToWasmTest() Review-Url: https://codereview.chromium.org/2079393003 Cr-Commit-Position: refs/heads/master@{#37132}
-
- 17 Jun, 2016 3 commits
-
-
jgruber authored
As a first step towards showing builtin frames in stack traces, we will now push target and new target unconditionally. Since the various specializations of BuiltinArguments are made redundant by this change, we can remove them and all related code. R=bmeurer@chromium.org BUG= Review-Url: https://codereview.chromium.org/2074063002 Cr-Commit-Position: refs/heads/master@{#37061}
-
jgruber authored
Construct a BUILTIN frame before throwing an exception from runtime. R=bmeurer@chromium.org BUG= Review-Url: https://codereview.chromium.org/2078443002 Cr-Commit-Position: refs/heads/master@{#37053}
-
jgruber authored
This adds a new BUILTIN frame type, which supports variable number of arguments for builtins implemented in hand-written native code (we will extend this mechanism to TurboFan builtins at some point). Convert the Math.max and Math.min builtins to construct a BUILTIN frame if required. This does not yet work for C++ builtins, but that'll be the next step. R=bmeurer@chromium.org, jarin@chromium.org BUG=v8:4815 LOG=n Review-Url: https://codereview.chromium.org/2069423002 Cr-Commit-Position: refs/heads/master@{#37051}
-
- 14 Jun, 2016 1 commit
-
-
yangguo authored
R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2068603002 Cr-Commit-Position: refs/heads/master@{#36960}
-
- 09 Jun, 2016 2 commits
-
-
jarin authored
This makes sure we do not compile ToNumber stub on demand. This makes it easier to use during concurrent compilation. Review-Url: https://codereview.chromium.org/2051113002 Cr-Commit-Position: refs/heads/master@{#36870}
-
jarin authored
Since some builtins use StringToNumberStub (so the code is always there), it makes more sense to have StringToNumber builtin. Review-Url: https://codereview.chromium.org/2050853003 Cr-Commit-Position: refs/heads/master@{#36843}
-
- 07 Jun, 2016 1 commit
-
-
mvstanton authored
It may be that we have a feedback vector, but no literals. In this case we can store into the OptimizedCodeMap directly instead of using a WeakCell, because all data in the feedback vector is already held weakly. The use of a WeakCell in the OptimizedCodeMap is only required when there are literals which may hold maps strongly. This is to address a performance regression caused by the creation of a large number of WeakCells. BUG=chromium:615831 Review-Url: https://codereview.chromium.org/2031123003 Cr-Commit-Position: refs/heads/master@{#36786}
-
- 03 Jun, 2016 1 commit
-
-
yangguo authored
R=*bmeurer@chromium.org, caitpotter88@gmail.com, *littledan@chromium.org, *ulan@chromium.org BUG=v8:4483 Review-Url: https://codereview.chromium.org/2033223003 Cr-Commit-Position: refs/heads/master@{#36718}
-
- 24 May, 2016 1 commit
-
-
neis authored
BUG=v8:4907 Review-Url: https://codereview.chromium.org/2006653003 Cr-Commit-Position: refs/heads/master@{#36467}
-
- 19 May, 2016 1 commit
-
-
rmcilroy authored
We cannot tier up from interpreted to baseline code when there is an activation of the function on the stack. This significantly regresses the performance of recursive functions since they are unlikely to get tiered up. This CL adds the ability for a function to be marked for baseline compilation when it returns. To do this we patch the InterpreterEntryTrampoline return address to point to InterpreterMarkBaselineOnReturn, which leaves the interpreted frame and recompile the function for baseline. This improves the score of EarlyBoyer by ~8x for Ignition. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1965343002 Cr-Commit-Position: refs/heads/master@{#36360}
-
- 18 May, 2016 1 commit
-
-
rmcilroy authored
In order to support compiling to baseline on return we need to be able to return to the actual return address. With this change this is what the Return bytecode now does, removing the need for the InterpreterExitTrampoline. This change also removes the InterpreterNotifyDeoptXXX builtins and unifies FCG and Igntion to both use NotifyDeoptXXX. As part of this change, FullCodegenerator::State is moved to Deoptimize::BailoutState. BUG=v8:4280 LOG=N Committed: https://crrev.com/34c9626e2ee56fe805de549697ca5323aed7cb66 Cr-Commit-Position: refs/heads/master@{#36288} Review-Url: https://codereview.chromium.org/1969423002 Cr-Commit-Position: refs/heads/master@{#36310}
-
- 17 May, 2016 2 commits
-
-
machenbach authored
Revert of [Interpreter] Remove InterpreterExitTrampoline and replace with returning to the entry trampoline. (patchset #6 id:170001 of https://codereview.chromium.org/1969423002/ ) Reason for revert: Breaks https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm%20-%20sim/builds/619 Might only affect pure release builds? Original issue's description: > [Interpreter] Remove InterpreterExitTrampoline and replace with returning to the entry trampoline. > > In order to support compiling to baseline on return we need to be able to > return to the actual return address. With this change this is what the > Return bytecode now does, removing the need for the > InterpreterExitTrampoline. > > This change also removes the InterpreterNotifyDeoptXXX builtins and > unifies FCG and Igntion to both use NotifyDeoptXXX. As part of this > change, FullCodegenerator::State is moved to Deoptimize::BailoutState. > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/34c9626e2ee56fe805de549697ca5323aed7cb66 > Cr-Commit-Position: refs/heads/master@{#36288} TBR=mstarzinger@chromium.org,oth@chromium.org,rmcilroy@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review-Url: https://codereview.chromium.org/1986353002 Cr-Commit-Position: refs/heads/master@{#36294}
-
rmcilroy authored
In order to support compiling to baseline on return we need to be able to return to the actual return address. With this change this is what the Return bytecode now does, removing the need for the InterpreterExitTrampoline. This change also removes the InterpreterNotifyDeoptXXX builtins and unifies FCG and Igntion to both use NotifyDeoptXXX. As part of this change, FullCodegenerator::State is moved to Deoptimize::BailoutState. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1969423002 Cr-Commit-Position: refs/heads/master@{#36288}
-