- 23 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I0023200c54fa6499ae4e2cf5e4c89407cc35f187 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624218Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61762}
-
- 22 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I79e0553e8a0d6dac2aa16b94a6c0e05b6ccde4a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621934 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61725}
-
- 31 Jul, 2018 1 commit
-
-
Georg Neis authored
The heap broker expects that handles get canonicalized. R=jarin@chromium.org Bug: v8:7790 Change-Id: If6162316bb2a256e783a8175ac7d4172d040b28b Reviewed-on: https://chromium-review.googlesource.com/1155123 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#54823}
-
- 18 Jul, 2017 1 commit
-
-
Camillo Bruni authored
- use asm_tester instead of data variable name - directly expose Variable and Label for convenience Change-Id: I211fe07e236f96067037ca00c1435c1491121e6b Reviewed-on: https://chromium-review.googlesource.com/574914 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#46738}
-
- 07 Apr, 2017 1 commit
-
-
jgruber authored
The spec requires truncation while ToUint32 originally rounded down. This also adds a bunch of test cases to check edge case behavior. BUG=v8:6212 Review-Url: https://codereview.chromium.org/2805783003 Cr-Commit-Position: refs/heads/master@{#44487}
-
- 16 Nov, 2016 2 commits
-
-
jkummerow authored
This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
-
machenbach authored
Revert of [refactoring] Split CodeAssemblerState out of CodeAssembler (patchset #8 id:140001 of https://codereview.chromium.org/2498073002/ ) Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared doesn't want to compile. Missing export annotation? Original issue's description: > [refactoring] Split CodeAssemblerState out of CodeAssembler > > This is in preparation for introducing more specialized > CodeStubAssembler subclasses. The state object can be handed > around, while the Assembler instances are temporary-scoped. > > BUG=v8:5628 TBR=ishell@chromium.org,mstarzinger@chromium.org,jkummerow@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5628 Review-Url: https://codereview.chromium.org/2504913002 Cr-Commit-Position: refs/heads/master@{#41018}
-
- 15 Nov, 2016 1 commit
-
-
jkummerow authored
This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Review-Url: https://codereview.chromium.org/2498073002 Cr-Commit-Position: refs/heads/master@{#41015}
-
- 01 Sep, 2016 1 commit
-
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. Many of these files we need to rebuild are cctests which pull in more includes than they need. BUG=v8:5294 Review-Url: https://codereview.chromium.org/2304553002 Cr-Commit-Position: refs/heads/master@{#39080}
-
- 26 Aug, 2016 1 commit
-
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. Many of these files we need to rebuild are cctests which pull in more includes than they need. BUG=v8:5294 Review-Url: https://codereview.chromium.org/2278103002 Cr-Commit-Position: refs/heads/master@{#38933}
-
- 23 Aug, 2016 1 commit
-
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. Fixing it: - Don't include stuff in headers unless necessary. - Include the stuff you need, not some other stuff that happens to include the stuff you need. BUG=v8:5294 Review-Url: https://codereview.chromium.org/2268303002 Cr-Commit-Position: refs/heads/master@{#38818}
-
- 22 Aug, 2016 1 commit
-
-
marja authored
This makes us able to get rid of dependencies to parser.h from places which only need the ParseInfo, and also gets rid of the curious Parser <-> Compiler circular dependency. Also IWYUd where necessary. BUG= Review-Url: https://codereview.chromium.org/2268513002 Cr-Commit-Position: refs/heads/master@{#38777}
-
- 01 Aug, 2016 1 commit
-
-
mstarzinger authored
This switches our inlining tests (i.e. cctest/test-run-inlining) to rely on global object instead of function context specialization, which is more in sync with what we are actually shipping. It will also allow us to test inlining with the BytecodeGraphBuilder without having to add support for function context specialization just for testing purposes. R=bmeurer@chromium.org TEST=cctest/test-run-inlining BUG=v8:5251 Review-Url: https://codereview.chromium.org/2200673002 Cr-Commit-Position: refs/heads/master@{#38209}
-
- 25 Jul, 2016 1 commit
-
-
rmcilroy authored
Always use the BytecodeGraphBuilder when the --turbo-from-bytecode is enabled, assuming the function should be compiled for Ignition. Adds a new MaybeOptimizeIgnition function to runtime-profiler which is called if the function should be optimized from bytecode rather than going via full-codegen. BUG=v8:4280 Committed: https://crrev.com/9ca7db914be88e6792a88eab4a1988ee031d70c4 Review-Url: https://codereview.chromium.org/2156753002 Cr-Original-Commit-Position: refs/heads/master@{#37921} Cr-Commit-Position: refs/heads/master@{#38002}
-
- 21 Jul, 2016 2 commits
-
-
machenbach authored
Revert of [Intepreter] Always use BytecodeGraphBuilder when --turbo-from-bytecode (patchset #3 id:80001 of https://codereview.chromium.org/2156753002/ ) Reason for revert: Breaks tsan: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/10758 Original issue's description: > [Intepreter] Always use BytecodeGraphBuilder when --turbo-from-bytecode > > Always use the BytecodeGraphBuilder when the --turbo-from-bytecode > is enabled, assuming the function should be compiled for Ignition. > Adds a new MaybeOptimizeIgnition function to runtime-profiler > which is called if the function should be optimized from bytecode > rather than going via full-codegen. > > BUG=v8:4280 > > Committed: https://crrev.com/9ca7db914be88e6792a88eab4a1988ee031d70c4 > Cr-Commit-Position: refs/heads/master@{#37921} TBR=mstarzinger@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/2165223002 Cr-Commit-Position: refs/heads/master@{#37925}
-
rmcilroy authored
Always use the BytecodeGraphBuilder when the --turbo-from-bytecode is enabled, assuming the function should be compiled for Ignition. Adds a new MaybeOptimizeIgnition function to runtime-profiler which is called if the function should be optimized from bytecode rather than going via full-codegen. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2156753002 Cr-Commit-Position: refs/heads/master@{#37921}
-
- 17 Jun, 2016 1 commit
-
-
ishell authored
... and a drive-by-fix of a comment generation in CodeAssembler. Review-Url: https://codereview.chromium.org/2076953002 Cr-Commit-Position: refs/heads/master@{#37070}
-
- 02 Jun, 2016 1 commit
-
-
ishell authored
[stubs] Extend HasProperty stub with dictionary-mode, string wrapper and double-elements objects support. This CL also replaces some Branch() usages with GotoIf/GotoUnless. (This is a reland after fixing issues that prevented this CL from landing in other CLs). BUG=v8:2743 LOG=Y Committed: https://crrev.com/24066b6df4259b302edfa1db884c479008776a7e Cr-Commit-Position: refs/heads/master@{#36657} Review-Url: https://codereview.chromium.org/1995453002 Cr-Commit-Position: refs/heads/master@{#36686}
-
- 01 Jun, 2016 2 commits
-
-
ishell authored
Revert of Extend HasProperty stub with dictionary-mode and double-elements objects support. (patchset #8 id:280001 of https://codereview.chromium.org/1995453002/ ) Reason for revert: There are crashes on Win32 and Win64 bots. Original issue's description: > Extend HasProperty stub with dictionary-mode, string wrapper and double-elements objects support. > > This CL also replaces some Branch() usages with GotoIf/GotoUnless. > > BUG=v8:2743 > LOG=Y > > Committed: https://crrev.com/24066b6df4259b302edfa1db884c479008776a7e > Cr-Commit-Position: refs/heads/master@{#36657} TBR=verwaest@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:2743 Review-Url: https://codereview.chromium.org/2028333002 Cr-Commit-Position: refs/heads/master@{#36659}
-
ishell authored
This CL also replaces some Branch() usages with GotoIf/GotoUnless. BUG=v8:2743 LOG=Y Review-Url: https://codereview.chromium.org/1995453002 Cr-Commit-Position: refs/heads/master@{#36657}
-
- 27 May, 2016 1 commit
-
-
mvstanton authored
We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. BUG= Review-Url: https://codereview.chromium.org/1906823002 Cr-Commit-Position: refs/heads/master@{#36539}
-
- 29 Apr, 2016 1 commit
-
-
mstarzinger authored
This adds a dedicated flag for enabling the BytecodeGraphBuilder. The intention is to be explicit when this variant is being tested and to avoid unnecessary overhead in production code for a configuration that is not yet shipping. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/1925123002 Cr-Commit-Position: refs/heads/master@{#35892}
-
- 27 Apr, 2016 2 commits
-
-
mstarzinger authored
This makes sure that the testing pipeline withing the FunctionTester class only performs AST analysis and deoptimization preparation when graphs are generated from the AST (as opposed to from bytecode). R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/1928523002 Cr-Commit-Position: refs/heads/master@{#35827}
-
bmeurer authored
Refactor the TurboFan pipeline to allow for concurrent recompilation in the same way that Crankshaft does it. For now we limit the concurrent phases to scheduling, instruction selection, register allocation and jump threading. R=mstarzinger@chromium.org, ahaas@chromium.org, jarin@chromium.org Review URL: https://codereview.chromium.org/1179393008 Cr-Commit-Position: refs/heads/master@{#35818}
-
- 18 Apr, 2016 1 commit
-
-
mstarzinger authored
This disables parsing when we optimize directly from bytecode using TurboFan, because TurboFan is capable of building graphs out of the bytecode directly. R=bmeurer@chromium.org BUG=v8:4280 LOG=n Review URL: https://codereview.chromium.org/1891663004 Cr-Commit-Position: refs/heads/master@{#35567}
-
- 11 Apr, 2016 1 commit
-
-
bmeurer authored
We had exactly one test case for --noturbo-types, so it's likely that the generic pipeline (without types) was already broken for quite some time, plus no one expressed interest in maintaining it, plus it complicates the JSGenericLowering integration. So decision is to kill it. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1872333002 Cr-Commit-Position: refs/heads/master@{#35387}
-
- 08 Apr, 2016 1 commit
-
-
mstarzinger authored
The parser should never need to look at the underlying closure object, hence the field can be moved from ParseInfo into CompilationInfo. R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1863083002 Cr-Commit-Position: refs/heads/master@{#35358}
-
- 01 Apr, 2016 1 commit
-
-
jochen authored
We expect that the majority of malloc'd memory held by V8 is allocated in Zone objects. Introduce an Allocator class that is used by Zones to manage memory, and allows for querying the current usage. BUG=none R=titzer@chromium.org,bmeurer@chromium.org,jarin@chromium.org LOG=n TBR=rossberg@chromium.org Review URL: https://codereview.chromium.org/1847543002 Cr-Commit-Position: refs/heads/master@{#35196}
-
- 18 Feb, 2016 1 commit
-
-
jarin authored
Review URL: https://codereview.chromium.org/1711513003 Cr-Commit-Position: refs/heads/master@{#34103}
-
- 12 Feb, 2016 1 commit
-
-
titzer authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1692223002 Cr-Commit-Position: refs/heads/master@{#33954}
-
- 10 Feb, 2016 1 commit
-
-
mstarzinger authored
The field in question is only needed when the optimizing compiler is triggered via OSR. All other paths (e.g. from bytecode stream) should not rely on the unoptimized code being present. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1685633002 Cr-Commit-Position: refs/heads/master@{#33860}
-
- 05 Feb, 2016 1 commit
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ ) Reason for revert: Must revert for now due to chromium api natives issues. Original issue's description: > Type Feedback Vector lives in the closure > > (RELAND: the problem before was a missing write barrier for adding the code > entry to the new closure. It's been addressed with a new macro instruction > and test. The only change to this CL is the addition of two calls to > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. > And Benedikt reviewed it as well. > > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org > > BUG= > > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 > Cr-Commit-Position: refs/heads/master@{#33741} TBR=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/1670813005 Cr-Commit-Position: refs/heads/master@{#33766}
-
- 04 Feb, 2016 1 commit
-
-
mvstanton authored
(RELAND: the problem before was a missing write barrier for adding the code entry to the new closure. It's been addressed with a new macro instruction and test. The only change to this CL is the addition of two calls to __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. And Benedikt reviewed it as well. TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1668103002 Cr-Commit-Position: refs/heads/master@{#33741}
-
- 27 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ ) Reason for revert: Bug: failing to use write barrier when writing code entry into closure. Original issue's description: > Reland of Type Feedback Vector lives in the closure > > (Fixed a bug found by nosnap builds.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > BUG= > > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1 > Cr-Commit-Position: refs/heads/master@{#33548} TBR=bmeurer@chromium.org,yangguo@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/1643533003 Cr-Commit-Position: refs/heads/master@{#33556}
-
mvstanton authored
(Fixed a bug found by nosnap builds.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1642613002 Cr-Commit-Position: refs/heads/master@{#33548}
-
- 26 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ ) Reason for revert: FAilure on win32 bot, need to investigate webkit failures. Original issue's description: > Type Feedback Vector lives in the closure > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > > BUG= > > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4 > Cr-Commit-Position: refs/heads/master@{#33518} TBR=bmeurer@chromium.org,akos.palfi@imgtec.com # 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/1632993003 Cr-Commit-Position: refs/heads/master@{#33520}
-
mvstanton authored
We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1563213002 Cr-Commit-Position: refs/heads/master@{#33518}
-
- 02 Dec, 2015 1 commit
-
-
danno authored
* Add a sibling interface to InterpreterAssembler called CodeStubAssembler which provides a wrapper around the RawMachineAssembler and is intented to make it easy to build efficient cross-platform code stubs. Much of the implementation of CodeStubAssembler is shamelessly stolen from the InterpreterAssembler, and the idea is to eventually merge the two interfaces somehow, probably moving the InterpreterAssembler interface over to use the CodeStubAssembler. Short-term, however, the two interfaces shall remain decoupled to increase our velocity developing the two systems in parallel. * Implement the StringLength stub in TurboFan with the new CodeStubAssembler. Replace and remove the old Hydrogen-stub version. * Remove a whole slew of machinery to support JavaScript-style code stub generation, since it ultimately proved unwieldy, brittle and baroque. This cleanup includes removing the shared code stub context, several example stubs and a tangle of build file changes. BUG=v8:4587 LOG=n Review URL: https://codereview.chromium.org/1475953002 Cr-Commit-Position: refs/heads/master@{#32508}
-
- 26 Nov, 2015 1 commit
-
-
rossberg authored
Moves all files related to AST and scopes into ast/, and all files related to scanner & parser to parsing/. Also eliminates a couple of spurious dependencies. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1481613002 Cr-Commit-Position: refs/heads/master@{#32351}
-
- 16 Nov, 2015 1 commit
-
-
jochen authored
BUG=none R=verwaest@chromium.org,rossberg@chromium.org,bmeurer@chromium.org,neis@chromium.org LOG=y Review URL: https://codereview.chromium.org/1413463006 Cr-Commit-Position: refs/heads/master@{#32014}
-