- 22 May, 2017 1 commit
-
-
Wiktor Garbacz authored
Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9 Reviewed-on: https://chromium-review.googlesource.com/507287Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#45458}
-
- 28 Apr, 2017 1 commit
-
-
jarin authored
BUG=v8:6325 Review-Url: https://codereview.chromium.org/2851723002 Cr-Commit-Position: refs/heads/master@{#44974}
-
- 03 Mar, 2017 1 commit
-
-
tebbi authored
Following the design of https://codereview.chromium.org/2692753004, also compute the arguments length in the deoptimizer sucht that it does not have to be computed in optimized code. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2729163002 Cr-Commit-Position: refs/heads/master@{#43587}
-
- 28 Feb, 2017 1 commit
-
-
tebbi authored
The new NewUnmappedArgumentsElements node now takes two inputs: - the frame holding the arguments (current frame or arguments adaptor frame) - the length of the suffix of passed arguments to be copied into the backing store These inputs are computed with two new node types: ArgumentsFrame() ArgumentsLength[formal_parameter_count,is_rest_length](Node* arguments_frame) The node type NewRestParameterElements can now be expressed with NewUnmappedArgumentsElements and an appropriate length and is thus not needed anymore. In escape analysis, we lower loads from the length field of NewUnmappedArgumentsElements with its length input and if we find out that no write access to the arguments elements exists, we replace element loads with direct stack access and replace the NewUnmappedArgumentsElements node with a node of the new node type ArgumentsElementsState. This corresponds to an ObjectState node and gets translated into a deoptimizer instruction to allocate the backing store. Together with the already existing deoptimizer support for the actual arguments object/rest parameters, this allows to remove all allocations for arguments objects/rest parameters in this case. In the deoptimizer, we read the actual parameters from the stack while transforming the static deopt info into TranslatedValue objects. If escape analysis cannot remove the backing store allocation, NewUnmappedArgumentsElements gets lo BUG=v8:5726 Review-Url: https://codereview.chromium.org/2692753004 Cr-Commit-Position: refs/heads/master@{#43475}
-
- 27 Feb, 2017 1 commit
-
-
Michael Starzinger authored
Nodes having the {Throw} operator are just used as terminators for control-flow leaving the function body with an exception completion, they turn into basic-block terminators within the schedule. Actually raising an exception is done solely via runtime calls. Hence {Throw} nodes no longer need any value input. R=bmeurer@chromium.org Change-Id: Id6d8e46b12c4b84f4e7a8ac96623c8efb1f27b26 Reviewed-on: https://chromium-review.googlesource.com/446501 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#43445}
-
- 22 Feb, 2017 1 commit
-
-
Andreas Haas authored
With this CL the out-of-line code of TrapIf will call a builtin instead of doing a direct runtime call, which is cheaper. In the best case, the out-of-line code now consists of a single call instruction. The builtin will load the trapID and then call the runtime to throw a trap. R=titzer@chromium.org, clemensh@chromium.org Change-Id: I8a75ba09f40236a3d5cbdc17c1317baf0a3c915a Reviewed-on: https://chromium-review.googlesource.com/445937 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#43366}
-
- 10 Feb, 2017 1 commit
-
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2682143002 Cr-Original-Commit-Position: refs/heads/master@{#43065} Committed: https://chromium.googlesource.com/v8/v8/+/193a0c118845d068ab386b5c90d04daaa64e1e86 Review-Url: https://codereview.chromium.org/2682143002 Cr-Commit-Position: refs/heads/master@{#43085}
-
- 09 Feb, 2017 2 commits
-
-
machenbach authored
Revert of [compiler] Pass deoptimization_kind through DeoptimizeParameters and FlagsContinuation (patchset #3 id:40001 of https://codereview.chromium.org/2682143002/ ) Reason for revert: cfi failure: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20cfi/builds/8635 Original issue's description: > [compiler] Pass deoptimization_kind through DeoptimizeParameters and FlagsContinuation > > BUG= > > Review-Url: https://codereview.chromium.org/2682143002 > Cr-Commit-Position: refs/heads/master@{#43065} > Committed: https://chromium.googlesource.com/v8/v8/+/193a0c118845d068ab386b5c90d04daaa64e1e86 TBR=jarin@chromium.org,verwaest@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/2683203002 Cr-Commit-Position: refs/heads/master@{#43070}
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2682143002 Cr-Commit-Position: refs/heads/master@{#43065}
-
- 26 Jan, 2017 2 commits
-
-
bmeurer authored
We turn a JSCallFunction node for f.apply(receiver, arguments) into a JSCallForwardVarargs node, when the arguments refers to the arguments of the outermost optimized code object, i.e. not an inlined arguments, and the apply method refers to Function.prototype.apply, and there's no other user of arguments except in frame states. We also replace the arguments node in the graph with a marker for the Deoptimizer similar to Crankshaft to make sure we don't materialize unused arguments just for the sake of deoptimization. We plan to replace this with a saner EscapeAnalysis based solution soon. R=jarin@chromium.org BUG=v8:5267,v8:5726 Review-Url: https://codereview.chromium.org/2655233002 Cr-Commit-Position: refs/heads/master@{#42680}
-
bbudge authored
- Adds Int16x8, Int8x16 types. - Adds neg, abs unary ops. - Adds add, sub, mul, and signed / unsigned min / max, comparison ops. LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2638133002 Cr-Commit-Position: refs/heads/master@{#42674}
-
- 17 Jan, 2017 1 commit
-
-
ahaas authored
The existing implementation assumes that return nodes have exactly one real value input. This assumption does not hold for WebAssembly. To avoid incorrect behavior, this CL turns of the reduction of returns with a value input count != 1. R=titzer@chromium.org, mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2638053002 Cr-Commit-Position: refs/heads/master@{#42425}
-
- 09 Jan, 2017 1 commit
-
-
marja authored
Downside: this adds all kinds of weird includes in the .cc files. (See design doc linked in the bug.) BUG=v8:5402 Review-Url: https://codereview.chromium.org/2622503002 Cr-Commit-Position: refs/heads/master@{#42140}
-
- 05 Jan, 2017 1 commit
-
-
leszeks authored
Add a more efficient encoding for state values that have a large number of optimized-out inputs. Review-Url: https://codereview.chromium.org/2509623002 Cr-Commit-Position: refs/heads/master@{#42088}
-
- 15 Dec, 2016 1 commit
-
-
ahaas authored
Some instructions in WebAssembly trap for some inputs, which means that the execution is terminated and (at least at the moment) a JavaScript exception is thrown. Examples for traps are out-of-bounds memory accesses, or integer divisions by zero. Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5 TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position constant), in addition to the trap condition itself. Additionally, each WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose number of inputs is linear to the number of trap checks in the function. Especially for functions with high numbers of trap checks we observe a significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing a TrapIf common operator only a single node is necessary per trap check, in addition to the trap condition. Also the nodes which are shared between trap checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a speedup of 30-50% on average. This CL only implements TrapIf and TrapUnless on x64. The implementation is also hidden behind the --wasm-trap-if flag. Please take a special look at how the source position is transfered from the instruction selector to the code generator, and at the context that is used for the runtime call. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2562393002 Cr-Commit-Position: refs/heads/master@{#41720}
-
- 06 Dec, 2016 1 commit
-
-
gdeepti authored
R=bbudge@chromium.org, titzer@chromium.org Review-Url: https://codereview.chromium.org/2385393002 Cr-Commit-Position: refs/heads/master@{#41505}
-
- 11 Nov, 2016 1 commit
-
-
bmeurer authored
This adds a new ExternalPointer type, which is an Internal type that is used for ExternalReferences and other pointer values, like the pointers into the asm.js heap. It also adds a PointerConstant operator, which we use to represents these raw constants (we can probably remove that particular operator again once WebAssembly ships with the validator). R=mvstanton@chromium.org BUG=v8:5267,v8:5270 Review-Url: https://codereview.chromium.org/2494753003 Cr-Commit-Position: refs/heads/master@{#40923}
-
- 08 Nov, 2016 1 commit
-
-
bmeurer authored
This adds a new TypedObjectState operator, which is a version of ObjectState that carries along MachineTypes for the inputs, so we can tell the deoptimizer how to interpret the inputs, instead of having to force everything to Tagged. Drive-by-fix: Remove the unused id parameter from ObjectState. R=tebbi@chromium.org BUG=v8:5609 Review-Url: https://codereview.chromium.org/2488623002 Cr-Commit-Position: refs/heads/master@{#40832}
-
- 02 Nov, 2016 2 commits
-
-
danno authored
This is preparation for using TF to create builtins that handle variable number of arguments and have to remove these arguments dynamically from the stack upon return. The gist of the changes: - Added a second argument to the Return node which specifies the number of stack slots to pop upon return in addition to those specified by the Linkage of the compiled function. - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should handles all tail-call cases except where the return value type differs, this fallback was not really useful and in fact caused unexpected behavior with variable sized argument popping, since it wasn't possible to materialize a Return node with the right pop count from the TailCall without additional context. - Modified existing Return generation to pass a constant zero as the additional pop argument since the variable pop functionality LOG=N Review-Url: https://codereview.chromium.org/2446543002 Cr-Commit-Position: refs/heads/master@{#40699}
-
machenbach authored
Revert of [turbofan] Support variable size argument popping in TF-generated functions (patchset #13 id:240001 of https://codereview.chromium.org/2446543002/ ) Reason for revert: Seems to break arm64 sim debug and blocks roll: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294 Original issue's description: > [turbofan] Support variable size argument removal in TF-generated functions > > This is preparation for using TF to create builtins that handle variable number of > arguments and have to remove these arguments dynamically from the stack upon > return. > > The gist of the changes: > - Added a second argument to the Return node which specifies the number of stack > slots to pop upon return in addition to those specified by the Linkage of the > compiled function. > - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should > handles all tail-call cases except where the return value type differs, this fallback > was not really useful and in fact caused unexpected behavior with variable > sized argument popping, since it wasn't possible to materialize a Return node > with the right pop count from the TailCall without additional context. > - Modified existing Return generation to pass a constant zero as the additional > pop argument since the variable pop functionality > > LOG=N TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2473643002 Cr-Commit-Position: refs/heads/master@{#40691}
-
- 31 Oct, 2016 1 commit
-
-
danno authored
This is preparation for using TF to create builtins that handle variable number of arguments and have to remove these arguments dynamically from the stack upon return. The gist of the changes: - Added a second argument to the Return node which specifies the number of stack slots to pop upon return in addition to those specified by the Linkage of the compiled function. - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should handles all tail-call cases except where the return value type differs, this fallback was not really useful and in fact caused unexpected behavior with variable sized argument popping, since it wasn't possible to materialize a Return node with the right pop count from the TailCall without additional context. - Modified existing Return generation to pass a constant zero as the additional pop argument since the variable pop functionality LOG=N Review-Url: https://codereview.chromium.org/2446543002 Cr-Commit-Position: refs/heads/master@{#40678}
-
- 27 Oct, 2016 1 commit
-
-
bmeurer authored
For inputs to truncating binary operations like <<, | or >>>, support all Oddballs not just undefined, true and false. This unifies treatment of these truncations in Crankshaft and TurboFan, and is very easy nowadays, since the memory layout of Oddball and HeapNumber is compatible. R=yangguo@chromium.org BUG=v8:5400 Review-Url: https://codereview.chromium.org/2452193003 Cr-Commit-Position: refs/heads/master@{#40608}
-
- 06 Oct, 2016 1 commit
-
-
jarin authored
Reland of "[turbofan] Osr value typing + dynamic type checks on entry. (patchset #5 id:80001 of https://codereview.chromium.org/2384113002/ )" Fixes: - Remove OsrGuards on frame specialization (for asm.js). - Handle the rename in the walk for native context. - Fix LoadContext effect wiring for Osr context chains. Review-Url: https://codereview.chromium.org/2388303006 Cr-Commit-Position: refs/heads/master@{#40021}
-
- 05 Oct, 2016 2 commits
-
-
jarin authored
Revert of [turbofan] Osr value typing + dynamic type checks on entry. (patchset #5 id:80001 of https://codereview.chromium.org/2384113002/ ) Reason for revert: Tanks the world. Original issue's description: > [turbofan] Osr value typing + dynamic type checks on entry. > > This introduces a new OsrGuard node that is inserted during graph building > to guard the inferred type of the OSR value. > > The type of the OSR value is inferred by running the typer before OSR > deconstruction, and then taking the type from the phi that takes the > OSR value. After the deconstruction, we throw the types away. > > At the moment we only support the SignedSmall OSR type and we always > pick the tagged representation. Later, we might want to support more > types (such as Number) and pick better representations (int32/float64). > > This CL also removes the OSR deconstruction tests because they build > unrealistic graph (no effect chain, no loop termination). I considered > adding the effect chains to the tests, but this would make the tests > even more brittle. > > Committed: https://crrev.com/1f5dc90a900d222da44bee3eff171a2ba1e3c076 > Cr-Commit-Position: refs/heads/master@{#39971} TBR=bmeurer@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/2395783002 Cr-Commit-Position: refs/heads/master@{#39985}
-
jarin authored
This introduces a new OsrGuard node that is inserted during graph building to guard the inferred type of the OSR value. The type of the OSR value is inferred by running the typer before OSR deconstruction, and then taking the type from the phi that takes the OSR value. After the deconstruction, we throw the types away. At the moment we only support the SignedSmall OSR type and we always pick the tagged representation. Later, we might want to support more types (such as Number) and pick better representations (int32/float64). This CL also removes the OSR deconstruction tests because they build unrealistic graph (no effect chain, no loop termination). I considered adding the effect chains to the tests, but this would make the tests even more brittle. Review-Url: https://codereview.chromium.org/2384113002 Cr-Commit-Position: refs/heads/master@{#39971}
-
- 20 Sep, 2016 1 commit
-
-
heimbuef authored
This is some initial cleanup to keep /src clean. The AccountingAllocator is actually exclusively used by zones and this common subfolder makes that more clear. BUG=v8:5409 Review-Url: https://codereview.chromium.org/2344143003 Cr-Commit-Position: refs/heads/master@{#39558}
-
- 22 Aug, 2016 1 commit
-
-
bmeurer authored
This adds cached versions of the DeoptimizeIf, DeoptimizeUnless and Deoptimize operators that occur most often in various benchmarks. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2266743002 Cr-Commit-Position: refs/heads/master@{#38769}
-
- 11 Aug, 2016 1 commit
-
-
bgeron authored
BUG= Review-Url: https://codereview.chromium.org/2227763004 Cr-Commit-Position: refs/heads/master@{#38586}
-
- 05 Aug, 2016 1 commit
-
-
jarin authored
If we infer loop variable bounds, we need to insert a type rename node (sigma) to make sure that simplified lowering can choose representations consistently. Review-Url: https://codereview.chromium.org/2222513002 Cr-Commit-Position: refs/heads/master@{#38391}
-
- 02 Aug, 2016 2 commits
-
-
mstarzinger authored
This completely removes translation of exception handler predictions from the graph IR. We now rely on the runtime using deoptimization infomation via {FrameSummary} for predictions in optimized code. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2207533002 Cr-Commit-Position: refs/heads/master@{#38250}
-
bmeurer authored
This adds support for lowering keyed access to JSTypedArray objects to element loads and stores instead of IC calls. There's still a lot of room for improvement, but the improvements can be done incrementally later. We add a dedicated UnsafePointerAdd operator, which sits in the effect chain, and does the (GC invisible) computation of addresses that are potentially inside HeapObjects. Also there's now a dedicated Retain operator, which ensures that we retain a certain tagged value, which is necessary to ensure that we keep a JSArrayBuffer alive as long as we might still potentially access elements in its backing store. R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2203693002 Cr-Commit-Position: refs/heads/master@{#38235}
-
- 27 Jul, 2016 1 commit
-
-
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}
-
- 22 Jul, 2016 1 commit
-
-
yangguo authored
This is in preparation to implementing exception prediction for async functions. Each handler table entry can now predict "caught", "uncaught", or "promise". The latter indicates that the exception will lead to a promise rejection. To mark the relevant try-catch blocks, we add a new native syntax. try { } %catch (e) { } indicates a TryCatchStatement with the "promise" prediction. The previous implementation of using the function to tell the relevant try-catch apart from inner try-catch blocks will not work for async functions since these can have inner try-catch blocks inside the same function. BUG=v8:5167 Review-Url: https://codereview.chromium.org/2161263003 Cr-Commit-Position: refs/heads/master@{#37966}
-
- 21 Jul, 2016 1 commit
-
-
bmeurer authored
We can actually eliminate certain effectful operations like loads and speculative number operations during representation selection if we discover that their value outputs are unused (we also propagate this information through pure operations as well, so that we remove the maximum number of effectful nodes possible). R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2168023002 Cr-Commit-Position: refs/heads/master@{#37928}
-
- 18 Jul, 2016 1 commit
-
-
bmeurer authored
So far TurboFan wasn't adding the deoptimization reasons for eager/soft deoptimization exits that can be used by either the DevTools profiler or the --trace-deopt flag. This adds basic support for deopt reasons on Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through the reasons to the code generation. Also moves the DeoptReason to it's own file (to resolve include cycles) and drops unused reasons. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2161543002 Cr-Commit-Position: refs/heads/master@{#37823}
-
- 15 Jul, 2016 1 commit
-
-
bgeron authored
With this patch, every node in turbo-*.json has an opcode, a title, and a label. The label field is new; the opcode and title were already there. The title is for the mouseover text. The label is what will be displayed in the graph view, unless it's too long, in which case only the opcode will be displayed. (This is similar to the preexisting behaviour of putting titles in labels, except that the titles were rarely short enough to fit in a label.) With this patch, the labels generated are in practice the same as the titles we had before, except for LoadField and StoreField, which will be rendered as LoadField[[+432]] and StoreField[[+432]] (if 432 was the offset). This diff adds an overloadable method virtual void Operator1<T>::PrintParameter(ostream&, PrintVerbosity) for each type T to Operator1. Its default implementation just uses operator<<(ostream&, T const&) and adds square brackets around it, but it is overridden for FieldAccess to print "[+432]" in the example case. BUG= R=jarin,danno Review-Url: https://codereview.chromium.org/2093013002 Cr-Commit-Position: refs/heads/master@{#37795}
-
- 14 Jul, 2016 1 commit
-
-
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}
-
- 21 Jun, 2016 1 commit
-
-
bmeurer authored
Add control dependencies to Projection and Int32Add/SubWithOverflow operators, to prevent the scheduler from moving the Projection nodes into the wrong place. This way the instruction selection can combine the Int32Add/SubWithOverflow operations with the DeoptimizeIf and/or DeoptimizeUnless nodes. This needs new operators CheckedInt32Add and CheckedInt32Sub so that we can delay the actual lowering until the effect/control linearizer. This also makes CheckIf operator obsolete, so we can drop it. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2082993002 Cr-Commit-Position: refs/heads/master@{#37148}
-
- 20 Jun, 2016 1 commit
-
-
bmeurer authored
These are used to check for Smi or HeapObject, and we use them appropriately in JSNativeContextSpecialization, so we don't need to introduce dependencies on concrete control flow and/or concrete frame states. They will be optimized by a proper check elimination reducer, which will be added in a separate CL. R=jarin@chromium.org BUG=v8:4470 Review-Url: https://codereview.chromium.org/2082523002 Cr-Commit-Position: refs/heads/master@{#37096}
-
- 06 Jun, 2016 1 commit
-
-
bgeron authored
Previously, ZoneVector<MachineType>* printed just as a pointer; now we print each MachineType in it, separated by commas. BUG= Review-Url: https://codereview.chromium.org/2030323002 Cr-Commit-Position: refs/heads/master@{#36736}
-