- 27 Oct, 2016 1 commit
-
-
leszeks authored
Reuses (and renames) the SFI "mark for optimization" flag to also permit marking for baseline recompilation. The flag now represents a "tier up" request, and CompileLazy can get baseline code as well as optimized code. BUG=v8:5512 Review-Url: https://codereview.chromium.org/2448933002 Cr-Commit-Position: refs/heads/master@{#40612}
-
- 21 Oct, 2016 1 commit
-
-
leszeks authored
The current method of marking functions for optimization, which replaces the JSFunction's code object with one that triggers optimization, would never allow unnamed functions to be optimized. This is an issue for a style of programming which heavily relies on passing around closures. This patch sets a bit on the SharedFunctionInfo when a JSFunction is marked. When another JSFunction referring to the same SharedFunctionInfo is lazily compiled, it immediately triggers a non-concurrent optimize. BUG=v8:5512 Review-Url: https://chromiumcodereview.appspot.com/2437043002 Cr-Commit-Position: refs/heads/master@{#40506}
-
- 18 Oct, 2016 1 commit
-
-
bmeurer authored
This slot is completely unused and always undefined anyways, so there's no need to maintain the slot during object construction. R=yangguo@chromium.org BUG=v8:5049 Review-Url: https://codereview.chromium.org/2423323002 Cr-Commit-Position: refs/heads/master@{#40377}
-
- 07 Oct, 2016 6 commits
-
-
jgruber authored
BUG= Committed: https://crrev.com/7db0ecdec3cf330766575cb7973b983f3f1e3020 Review-Url: https://codereview.chromium.org/2381843002 Cr-Original-Commit-Position: refs/heads/master@{#40080} Cr-Commit-Position: refs/heads/master@{#40087}
-
Mike Stanton authored
(GcStress failure was unrelated.) At one time, we hoped to generate the same code for different native contexts. But in truth, much performance comes from optimizing on the native context. Now we abandon this pathway. BUG= TBR=bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true Review URL: https://codereview.chromium.org/2402663002 . Cr-Commit-Position: refs/heads/master@{#40086}
-
jgruber authored
This reverts commit 7db0ecde. Manual revert since automatic revert is too large for the web interface. BUG= TBR=bmeurer@chromium.org,mstarzinger@chromium.org,yangguo@chromium.org,ahaas@chromium.org NOPRESUBMIT=true NOTREECHECKS=true Review-Url: https://codereview.chromium.org/2396353002 Cr-Commit-Position: refs/heads/master@{#40082}
-
mvstanton authored
Revert of [turbofan] Discard the shared code entry in the optimized code map. (patchset #3 id:40001 of https://codereview.chromium.org/2401653002/ ) Reason for revert: Possible GCSTRESS failure, investigating. Original issue's description: > [turbofan] Discard the shared code entry in the optimized code map. > > At one time, we hoped to generate the same code for different > native contexts. But in truth, much performance comes from optimizing > on the native context. Now we abandon this pathway. > > BUG= > > Committed: https://crrev.com/55af3c44c99a6e4cd6d53df775023d760ad2b2c3 > Cr-Commit-Position: refs/heads/master@{#40079} TBR=mstarzinger@chromium.org,ishell@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2403453002 Cr-Commit-Position: refs/heads/master@{#40081}
-
jgruber authored
BUG= Review-Url: https://codereview.chromium.org/2381843002 Cr-Commit-Position: refs/heads/master@{#40080}
-
mvstanton authored
At one time, we hoped to generate the same code for different native contexts. But in truth, much performance comes from optimizing on the native context. Now we abandon this pathway. BUG= Review-Url: https://codereview.chromium.org/2401653002 Cr-Commit-Position: refs/heads/master@{#40079}
-
- 06 Oct, 2016 1 commit
-
-
tebbi authored
BUG=v8:5431 Review-Url: https://codereview.chromium.org/2372113004 Cr-Commit-Position: refs/heads/master@{#40051}
-
- 29 Sep, 2016 1 commit
-
-
tebbi authored
R=bmeurer@chromium.org BUG= Review-Url: https://codereview.chromium.org/2380973002 Cr-Commit-Position: refs/heads/master@{#39872}
-
- 16 Sep, 2016 1 commit
-
-
mythria authored
In ignition, arguments to function calls and function constructors are pushed onto the stack before calling the function. It is required to check that stack does not overflow when pushing the arguments. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2335513004 Cr-Commit-Position: refs/heads/master@{#39470}
-
- 15 Sep, 2016 1 commit
-
-
Alexander.Gilday2 authored
Migrate the platform DatePrototype_GetField (and all wrappers) to TurboFan. BUG=v8:5049 Review-Url: https://codereview.chromium.org/2263533002 Cr-Commit-Position: refs/heads/master@{#39438}
-
- 14 Sep, 2016 1 commit
-
-
bmeurer authored
Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
-
- 12 Sep, 2016 1 commit
-
-
Alexander.Gilday2 authored
Migrate ToNumber platform builtin to TurboFan. Also move NonNumberToNumber builtin implementation to helper function. BUG=v8:5049 Review-Url: https://codereview.chromium.org/2327703003 Cr-Commit-Position: refs/heads/master@{#39343}
-
- 08 Sep, 2016 1 commit
-
-
mythria authored
Adds support to collect allocation site feedback for Array function calls to the call bytecode handler. BUG=v8:4280, v8:4780 LOG=N Review-Url: https://codereview.chromium.org/2307903002 Cr-Commit-Position: refs/heads/master@{#39283}
-
- 02 Sep, 2016 1 commit
-
-
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. Reland of https://codereview.chromium.org/2190293003/ with a bug fix. BUG=v8:4280, v8:4780 LOG=N Review-Url: https://codereview.chromium.org/2225923003 Cr-Commit-Position: refs/heads/master@{#39120}
-
- 30 Aug, 2016 1 commit
-
-
jgruber authored
This was exposed on win64 and manifested as a negative offset during stack frame collection, i.e. pc < Code::instruction_start() for a BUILTIN frame. This happened because StackFrame::LookupCode returns the wrong code object when call is the last instruction in a code object: * pc is actually the return address for all but the topmost frame. * pc points at the next instruction after the call. * This is beyond the current code object if call is the last instruction. * Lookup itself is naive in that it just returns the first code object for which (next_code_obj_addr > pc). It does not check that pc is actually within [instruction_start, instruction_end[. * In this specific case, the pc (== return address) actually pointed at the beginning of the header of the next code object. * We finally calculated offset as (code->instruction_start() - pc), but with the wrong code object. This should be followed up by a proper fix at some point. For instance, this could be setting pc to (return address - 1) for all but the topmost frame. BUG=v8:5311 Review-Url: https://codereview.chromium.org/2284673002 Cr-Commit-Position: refs/heads/master@{#38996}
-
- 19 Aug, 2016 1 commit
-
-
mstarzinger authored
This fixes the self-healing mechanism for closures in the interpreter entry trampoline not that bytecode can be preserved even when baseline code is already available. R=rmcilroy@chromium.org TEST=cctest/test-compiler/IgnitionEntryTrampolineSelfHealing BUG=chromium:638225 Review-Url: https://codereview.chromium.org/2257143002 Cr-Commit-Position: refs/heads/master@{#38747}
-
- 17 Aug, 2016 1 commit
-
-
bradnelson authored
Our previous per-arch instantiation thunks for asm.js didn't support modules that had or were called with anything other than 3 arguments. Adding support for this. Addding a runtime test method to check if asm validation succeeded. Adding a test of validation with different argument count combinations. R=mstarzinger@chromium.org TEST=mjsunit/asm/asm-validator.js BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203 Review-Url: https://codereview.chromium.org/2229723002 Cr-Commit-Position: refs/heads/master@{#38688}
-
- 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}
-