- 12 Aug, 2016 2 commits
-
-
ahaas authored
Revert of [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject. (patchset #3 id:40001 of https://codereview.chromium.org/2229243003/ ) Reason for revert: There is a data race in the initialization of the Isolate::random_number_generator() Original issue's description: > [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject. > > This CL splits CodeGenerator::GenerateCode into two new functions: > AssembleCode and FinishCodeObject. AssembleCode does not access or > modify the JS heap, which means that AssembleCode can be executed on > background threads. FinishCodeObject allocates the generated code object > on the JS heap and therefore has to be executed on the main thread. > > Implementation details: > The GenerateCode function has been split just before out-of-line code is > assembled. The reason is that code stubs may be generated when > out-of-line code is assembled, which potentially allocates these code > stubs on the heap. > > - Parts of initialization of the CodeGenerator has been moved from the > constructor to an Initialize function so that we can instantiate an empty > CodeGenerator object in PipelineData. > > R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org > > Committed: https://crrev.com/03058a2187e32cc4080612181802086527c116a2 > Cr-Commit-Position: refs/heads/master@{#38604} TBR=bmeurer@chromium.org,mstarzinger@chromium.org,titzer@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/2240523003 Cr-Commit-Position: refs/heads/master@{#38605}
-
ahaas authored
This CL splits CodeGenerator::GenerateCode into two new functions: AssembleCode and FinishCodeObject. AssembleCode does not access or modify the JS heap, which means that AssembleCode can be executed on background threads. FinishCodeObject allocates the generated code object on the JS heap and therefore has to be executed on the main thread. Implementation details: The GenerateCode function has been split just before out-of-line code is assembled. The reason is that code stubs may be generated when out-of-line code is assembled, which potentially allocates these code stubs on the heap. - Parts of initialization of the CodeGenerator has been moved from the constructor to an Initialize function so that we can instantiate an empty CodeGenerator object in PipelineData. R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org Review-Url: https://codereview.chromium.org/2229243003 Cr-Commit-Position: refs/heads/master@{#38604}
-
- 11 Aug, 2016 1 commit
-
-
bmeurer authored
This adds a very first version of inlined Array.prototype.pop into TurboFan optimized code. We currently limit the inlining to fast object or smi elements, until the unclear situation around hole NaNs is resolved and we have a clear semantics inside the compiler. It's also probably overly defensive in when it's safe to inline the call to Array.prototype.pop, but we can always extend that later once we have sufficient trust in the implementation and see an actual need to extend it. BUG=v8:2229,v8:3952,v8:5267 R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2239703002 Cr-Commit-Position: refs/heads/master@{#38578}
-
- 09 Aug, 2016 1 commit
-
-
bgeron authored
It can now deal with multiple objects at the same time (but no aliasing), and it propagates store information upwards across effect chain splits. R=jarin BUG= Review-Url: https://codereview.chromium.org/2159303002 Cr-Commit-Position: refs/heads/master@{#38509}
-
- 08 Aug, 2016 1 commit
-
-
bmeurer authored
Introduce a dedicated MaybeGrowFastElements simplified operator, which tries to grow a fast elements backing store for a given element that should be added to an array/object. Use that to lower a growing keyed store to a sequence of 1) check index is a valid array index, 2) check stored value, 3) maybe grow elements backing store (and deoptimize if it would normalize), and 4) store the actual element. The actual growing is done by two dedicated GrowFastDoubleElements and GrowFastSmiOrObjectElements builtins, which are very similar to the GrowArrayElementsStub that is used by Crankshaft. Drive-by-fix: Turn CopyFixedArray into CopyFastSmiOrObjectElements builtin, similar to the new growing builtins, so we don't need to inline the store+write barrier for the elements into all optimized code objects anymore. Also fix a bug in the OperationTyper for NumberSilenceNaN, which was triggered by this change. BUG=v8:5272 Review-Url: https://codereview.chromium.org/2227493002 Cr-Commit-Position: refs/heads/master@{#38418}
-
- 05 Aug, 2016 3 commits
-
-
bmeurer authored
This extends JSNativeContextSpecialization with support for stores to fast object/smi element backing stores that are marked as copy-on-write. In this case we first call the CopyFixedArray builtin to take a copy of the elements backing store, and then store the new elements back to the object, and finally perform the actual element store. R=epertoso@chromium.org BUG=v8:4470 Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6 Review-Url: https://codereview.chromium.org/2218703003 Cr-Original-Commit-Position: refs/heads/master@{#38370} Cr-Commit-Position: refs/heads/master@{#38392}
-
bmeurer authored
Revert of [turbofan] Add support for copy-on-write element stores. (patchset #2 id:20001 of https://codereview.chromium.org/2218703003/ ) Reason for revert: Breaks tree? Original issue's description: > [turbofan] Add support for copy-on-write element stores. > > This extends JSNativeContextSpecialization with support for stores to > fast object/smi element backing stores that are marked as copy-on-write. > In this case we first call the CopyFixedArray builtin to take a copy of > the elements backing store, and then store the new elements back to the > object, and finally perform the actual element store. > > R=epertoso@chromium.org > BUG=v8:4470 > > Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6 > Cr-Commit-Position: refs/heads/master@{#38370} TBR=epertoso@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4470 Review-Url: https://codereview.chromium.org/2220513002 Cr-Commit-Position: refs/heads/master@{#38376}
-
bmeurer authored
This extends JSNativeContextSpecialization with support for stores to fast object/smi element backing stores that are marked as copy-on-write. In this case we first call the CopyFixedArray builtin to take a copy of the elements backing store, and then store the new elements back to the object, and finally perform the actual element store. R=epertoso@chromium.org BUG=v8:4470 Review-Url: https://codereview.chromium.org/2218703003 Cr-Commit-Position: refs/heads/master@{#38370}
-
- 03 Aug, 2016 1 commit
-
-
mstarzinger authored
This removes the frame state input representing the before-state from nodes having any int32 bitwise operator. Lowering that inserts number conversions of the inputs has to be disabled when deoptimization is enabled, because the frame state layout is no longer known. R=epertoso@chromium.org BUG=v8:5021,v8:4746 Review-Url: https://codereview.chromium.org/2194383004 Cr-Commit-Position: refs/heads/master@{#38280}
-
- 01 Aug, 2016 1 commit
-
-
bmeurer authored
Allow inlining of getters and setters into TurboFan optimized code. This just adds the basic machinery required to essentially inline the setter and getter dispatch code for the (keyed) load/store ICs. There'll be follow up CLs to also actually inline some of the interesting accessor functions itself, like the byteLength and friends for the TypedArrays. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2198473002 Cr-Commit-Position: refs/heads/master@{#38192}
-
- 29 Jul, 2016 2 commits
-
-
bmeurer authored
So far we always create explicit control flow for map checks during JSNativeContextSpecialization, or in the monomorphic case we used a CheckIf combined with a map comparison. In either case we cannot currently effectively utilize the map check information during load elimination to optimize (polymorphic) map checks and elements kind transitions. With the introduction of CheckMaps, we can now start optimizing map checks in a more effective fashion. This CL doesn't change anything in that direction yet, but merely changes the fundamental mechanism. This also removes the stable map optimization from the Typer, where it was always a bit odd, and puts it into the typed lowering and the native context specialization instead. R=epertoso@chromium.org BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2196653002 Cr-Commit-Position: refs/heads/master@{#38166}
-
bmeurer authored
R=mvstanton@chromium.org Review-Url: https://codereview.chromium.org/2195623002 Cr-Commit-Position: refs/heads/master@{#38160}
-
- 27 Jul, 2016 3 commits
-
-
bmeurer authored
Also run the BranchElimination (plus CommonOperatorReducer and the DeadCodeElimination) during the load elimination phase, so we can elminate some Phi nodes early on that would otherwise confuse the truncation analysis and/or representation selection, i.e. if there's a branch that is never taken, that would yield undefined, we'd have to choose tagged representation for the Phi, even if the always taken branch yields an integer. R=epertoso@chromium.org BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2190543002 Cr-Commit-Position: refs/heads/master@{#38088}
-
mstarzinger authored
This implements graph construction for entry via on-stack replacement within the {BytecodeGraphBuilder}. Entry points are at loop headers similar to previous OSR implementations. All interpreter registers are addressable via {OsrValue} nodes in the graph. Currently we rely on {OsrPoll} bytecodes to be placed right after loop headers (i.e. at the targets of back edges). R=jarin@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2171083004 Cr-Commit-Position: refs/heads/master@{#38083}
-
jarin authored
The new phase will detect loop variable, infer bounds and bake them into the type. Review-Url: https://codereview.chromium.org/2164263003 Cr-Commit-Position: refs/heads/master@{#38077}
-
- 26 Jul, 2016 1 commit
-
-
bmeurer authored
This works around the problem that the lowering for JSStackCheck doesn't play well with effect chain based state tracking, because it doesn't report the correct changes (we will address this with a better handling of stack checks soon). It also allows us to run the EarlyOptimizationPhase concurrently, which doesn't need to access the heap or generate code stubs. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2183033002 Cr-Commit-Position: refs/heads/master@{#38049}
-
- 25 Jul, 2016 3 commits
-
-
bmeurer authored
Turn the LoadElimination into a proper graph Reducer so that it can run together with ValueNumbering and RedundancyElimination to a fixpoint for maximum load/check elimination. This also adds initial support for eliminating redundant LoadElement/StoreElement nodes. BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2164253002 Cr-Commit-Position: refs/heads/master@{#38015}
-
jochen authored
R=ishell@chromium.org,bmeurer@chromium.org TBR=rossberg@chromium.org BUG= Review-Url: https://codereview.chromium.org/2175233003 Cr-Commit-Position: refs/heads/master@{#38009}
-
jochen authored
R=bmeurer@chromium.org BUG= Review-Url: https://codereview.chromium.org/2173403002 Cr-Commit-Position: refs/heads/master@{#38007}
-
- 22 Jul, 2016 2 commits
-
-
ivica.bogosavljevic authored
Implement UnalignedLoad and UnalignedStore optional turbofan operators and use them in WasmCompiler for unaligned memory access. BUG= Review-Url: https://codereview.chromium.org/2122853002 Cr-Commit-Position: refs/heads/master@{#37988}
-
rmcilroy authored
The effect control linearizer runs off-thread and needs the ToNumber call descriptor. Add a hack to create this on the main thread to ensure off-thread's don't race on it's construction. Also add a DCHEK to the CallInterfaceDescriptor to ensure they are always initilaized on the main thread. Review-Url: https://codereview.chromium.org/2168843003 Cr-Commit-Position: refs/heads/master@{#37973}
-
- 15 Jul, 2016 1 commit
-
-
jarin authored
Review-Url: https://codereview.chromium.org/2143163002 Cr-Commit-Position: refs/heads/master@{#37791}
-
- 14 Jul, 2016 3 commits
-
-
jarin authored
This CL introduces explicit LoopExit control nodes at loop exits. We also attach explicit value renames (LoopExitMarker) and effect rename (LoopExitEffect) to each loop exit. This is in preparation to loop peeling, which will replace LoopExit, LoopExitMarker and LoopExitEffect with Merge, Phi and EffectPhi respectively. At the moment, we insert loop exit at every return, break, continue and locally caught throw. We do not yet handle uncaught throws (including error throws, such as ReferenceError). Review-Url: https://codereview.chromium.org/2140673007 Cr-Commit-Position: refs/heads/master@{#37769}
-
bmeurer authored
If --turbo-type-feedback is off, the type hints on the operators will just be kAny, so we don't need to do additional checks in the JSTypedLowering reducer. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2144203002 Cr-Commit-Position: refs/heads/master@{#37750}
-
jarin authored
Review-Url: https://codereview.chromium.org/2145683004 Cr-Commit-Position: refs/heads/master@{#37745}
-
- 12 Jul, 2016 1 commit
-
-
mstarzinger authored
This widens the set of binary operator reductions that are applied by TurboFan when graphs are built from bytecode. By now we only insert number conversions to inputs of integer binary ops (i.e. bitwise and shifts), others no longer require a "before" frame state input. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2135973003 Cr-Commit-Position: refs/heads/master@{#37674}
-
- 11 Jul, 2016 2 commits
-
-
bmeurer authored
This is follow-up cleanup for the flags that are no longer used inside SimplifiedLowering. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2132403002 Cr-Commit-Position: refs/heads/master@{#37652}
-
bmeurer authored
Usually loops run from 0 to some array length l, which means the induction variable i will probably have type Unsigned32, just like the length l. The CheckBounds operation lowers to an Uint32LessThan comparison, so if we also lower the user level i < l comparison to Uint32LessThan (whenever possible), we get some bounds check elimination for free (via value numbering plus branch condition elimination). This merges the branch condition elimination phase with the late optimization phase to make this magic happen. R=jarin@chromium.org BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2135123002 Cr-Commit-Position: refs/heads/master@{#37629}
-
- 05 Jul, 2016 2 commits
-
-
bmeurer authored
This adds a new optimization phase to the TurboFan pipeline, which walks over the effect chain and tries to eliminate redundant loads (and even some stores) of object fields. We currently ignore element access, but that will probably need to be handled as well at some point. We also don't have any special treatment to properly track object maps, which is also on the list of things that will happen afterwards. The implementation is pretty simple currently, and probably way to inefficient. It's meant to be a proof-of-concept to iterate on. R=jarin@chromium.org BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2120253002 Cr-Commit-Position: refs/heads/master@{#37528}
-
bmeurer authored
We can already benefit from value numbering (pure) nodes at this point in the graph, because it makes some later passes more efficient and reduces the graph size early. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2125613002 Cr-Commit-Position: refs/heads/master@{#37523}
-
- 29 Jun, 2016 1 commit
-
-
bmeurer authored
It's not safe to magically compute types during representation selection, so better disable the Typer decorator before we start to do the representation/truncation analysis. This will also allow us to move to a world where we can run representation selection concurrently eventually. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2103363004 Cr-Commit-Position: refs/heads/master@{#37367}
-
- 27 Jun, 2016 1 commit
-
-
bbudge authored
Replaces ArchDefault method with Crankshaft and Turbofan getters. Eliminates IsAllocated method on Register, FloatRegister, DoubleRegister. Eliminates ToString method too. Changes call sites to access appropriate arch default RegisterConfiguration. LOG=N BUG= Review-Url: https://codereview.chromium.org/2092413002 Cr-Commit-Position: refs/heads/master@{#37297}
-
- 23 Jun, 2016 2 commits
-
-
bgeron authored
R=jarin@chromium.org BUG= Review-Url: https://codereview.chromium.org/2087483003 Cr-Commit-Position: refs/heads/master@{#37220}
-
bmeurer authored
The redundancy elimination is currently a graph reducer that tries to combine redundant checks in the effect chain. It does this by propagating the checks that happened along effect paths, which is pretty similar to what the BranchElimination does on the control chain. We run this reducer together with the other optimizations right after the representation selection. An upcoming CL will extend the redundancy elimination to also eliminate redundant loads (and eventually map checks). R=jarin@chromium.org BUG=v8:5141 Review-Url: https://codereview.chromium.org/2091503003 Cr-Commit-Position: refs/heads/master@{#37208}
-
- 22 Jun, 2016 1 commit
-
-
bmeurer authored
Let the SimplifiedOperatorReducer perform some strength reduction for certain CheckTaggedSigned and CheckTaggedPointer inputs (reusing the existing logic for ObjectIsSmi). R=jarin@chromium.org BUG=v8:5141 Review-Url: https://codereview.chromium.org/2080703006 Cr-Commit-Position: refs/heads/master@{#37167}
-
- 21 Jun, 2016 1 commit
-
-
bmeurer authored
We need to trim the graph before we execute the MemoryOptimizer, because that just walks the effect chain from Start to End and cannot deal with dead nodes in the use lists. R=jarin@chromium.org BUG=chromium:614292 Review-Url: https://codereview.chromium.org/2080703003 Cr-Commit-Position: refs/heads/master@{#37133}
-
- 13 Jun, 2016 2 commits
-
-
mvstanton authored
We'd like to track performance metrics in an automated way. This CL introduces --turbo-stats-nvp which exposes --turbo-stats information in {"name"=value} pair format. BUG= Review-Url: https://codereview.chromium.org/2053383002 Cr-Commit-Position: refs/heads/master@{#36919}
-
mtrofin authored
We were able to achieve our goals for register allocation independent of the allocation algorithm. Performance data so far is inconclusive re. the value of the Greedy algorithm, compared to the particular Linear Scan implementation we're currently using, and the performance measurement techniques we currently use are too imprecise to help with this matter. Retiring the algorithm to lower maintenance and evolution cost (e.g. lower cost of adding aliasing support). Once we improve benchmarking stability, and establish a suite sensitive enough for codegen improvement studies, we may revive the algorithm, should the need arise. BUG= Review-Url: https://codereview.chromium.org/2060673002 Cr-Commit-Position: refs/heads/master@{#36912}
-
- 07 Jun, 2016 1 commit
-
-
bmeurer authored
There's no point in trying to extract the type hints from the fullcodegen CompareICs, BinaryOpICs and ToBooleanICs if the feedback is not consumed (which is guarded by the flag). R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2048543002 Cr-Commit-Position: refs/heads/master@{#36768}
-
- 06 Jun, 2016 1 commit
-
-
cbruni authored
Passing in the isolate and pointer compare the instnance against the corresponding constant is always faster than decoding the instance types. BUG= Review-Url: https://codereview.chromium.org/2028983002 Cr-Commit-Position: refs/heads/master@{#36744}
-