- 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}
-
- 24 Feb, 2017 1 commit
-
-
neis authored
If the RHS is 0 and we have Smi feedback, speculate that the result (the LHS) will continue to be in the Unsigned31 range. This helps us avoid converting the result to double when merging with Signed32. R=jarin@chromium.org BUG= Review-Url: https://codereview.chromium.org/2709423002 Cr-Commit-Position: refs/heads/master@{#43415}
-
- 21 Feb, 2017 2 commits
-
-
bbudge authored
- Adds new machine types SimdBool4/8/16 for the different boolean vector types. - Adds a kSimdMaskRegisters flag for each platform. These are all false for now. - Removes Create, ExtractLane, ReplaceLane, Equal, NotEqual, Swizzle and Shuffle opcodes from the Boolean types. These are unlikely to be well supported natively, and can be synthesized using Select. - Changes the signature of Relational opcodes to return boolean vectors. - Changes the signature of Select opcodes to take boolean vectors. - Updates the ARM implementation of Relational and Select opcodes. LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2700813002 Cr-Commit-Position: refs/heads/master@{#43348}
-
neis authored
R=jarin@chromium.org BUG= Review-Url: https://codereview.chromium.org/2703113003 Cr-Commit-Position: refs/heads/master@{#43339}
-
- 18 Feb, 2017 1 commit
-
-
vabr authored
Currently, typeof o, where o is an undetectable callable object (such as document.all), returns 'function' if optimised. It should, however, return 'undefined'. This CL excludes undetectable objects from the optimization resulting in type 'function' and renames the related code to reflect that. BUG=v8:5972 R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2697063002 Cr-Commit-Position: refs/heads/master@{#43298}
-
- 16 Feb, 2017 1 commit
-
-
Michael Starzinger authored
This handles arithmetic addition operations during the early type-hint lowering (i.e. during graph construction). The string addition case is still handled by {JSTypedLowering} as it needs static type information. R=bmeurer@chromium.org Change-Id: I9df47dfc5bf7613c51f6d803ab43d5d3f6c21be8 Reviewed-on: https://chromium-review.googlesource.com/443185Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43235}
-
- 02 Feb, 2017 1 commit
-
-
bmeurer authored
This introduces additional verification logic to ensure that the condition passed to Branch/Select operators is always of type Boolean. CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win64_dbg TBR=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2672713002 Cr-Commit-Position: refs/heads/master@{#42875}
-
- 01 Feb, 2017 2 commits
-
-
bmeurer authored
Revert of [turbofan] Constant propagation for JumpIfFalse/JumpIfTrue. (patchset #4 id:60001 of https://codereview.chromium.org/2666283002/ ) Reason for revert: Breaks win64 it seems. Original issue's description: > [turbofan] Constant propagation for JumpIfFalse/JumpIfTrue. > > The JumpIfFalse and JumpIfTrue bytecodes test the accumulator, and > branch based on whether the accumulator is true or false (no other > value allowed, and in fact TurboFan would blow up if you would pass > anything else, since Branch operator can only deal with Boolean). > So for either branch we know exactly the value of the accumulator, > and we can update the environment to this constant value instead. > > This helps to avoid the useless bit materialization that currently > happens when || or && is being used in a value context. > > R=jarin@chromium.org > BUG=v8:5267 > > Review-Url: https://codereview.chromium.org/2666283002 > Cr-Commit-Position: refs/heads/master@{#42843} > Committed: https://chromium.googlesource.com/v8/v8/+/158ac9287193f315342ad31c38fe451620d176eb TBR=jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5267 Review-Url: https://codereview.chromium.org/2668933002 Cr-Commit-Position: refs/heads/master@{#42845}
-
bmeurer authored
The JumpIfFalse and JumpIfTrue bytecodes test the accumulator, and branch based on whether the accumulator is true or false (no other value allowed, and in fact TurboFan would blow up if you would pass anything else, since Branch operator can only deal with Boolean). So for either branch we know exactly the value of the accumulator, and we can update the environment to this constant value instead. This helps to avoid the useless bit materialization that currently happens when || or && is being used in a value context. R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2666283002 Cr-Commit-Position: refs/heads/master@{#42843}
-
- 31 Jan, 2017 1 commit
-
-
bmeurer authored
We cannot eliminate unused CheckFloat64Hole nodes, since loading from a holey array can have side-effects, i.e. triggering getters in the prototype chain. R=mvstanton@chromium.org BUG=chromium:686737 Review-Url: https://codereview.chromium.org/2665123002 Cr-Commit-Position: refs/heads/master@{#42806}
-
- 28 Jan, 2017 1 commit
-
-
jarin authored
This avoids using kTaggedSigned and kTaggedPointer because the semantic information of those type could be invalid in unreachable code. For example, SmiCheck(0.1) has representation TaggedSigned, but it is later compiled to DeoptimizeUnless(ObjectIsSmi(0.1)) with the constant 0.1 directly connected to the uses. If the use is state-values, which recorded the TaggedSigned representation of CheckSmi, the code generator will be confused because it will see constant 0.1 that claims to be TaggedSigned value. BUG=chromium:675704 Review-Url: https://codereview.chromium.org/2656243004 Cr-Commit-Position: refs/heads/master@{#42756}
-
- 27 Jan, 2017 1 commit
-
-
bmeurer authored
The StringIndexOf operation is pure on the JS level, but the actual stub call must be in the effect chain later so that the Scheduler doesn't place it inside some allocation region (The %StringIndexOf runtime function may trigger a GC for string flattening). BUG=chromium:685580 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2657243002 Cr-Commit-Position: refs/heads/master@{#42736}
-
- 26 Jan, 2017 1 commit
-
-
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}
-
- 19 Jan, 2017 1 commit
-
-
bmeurer authored
Properly recognize and optimize typeof in a strict/abstract equality comparison with the string literal "object" to a check for Null or a check of the map for Receiver instance type and non-callable. Drive-by-fix: Also optimize typeof o === "function" somewhat, now that we have the new types for Callable and NonCallable. R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2646763003 Cr-Commit-Position: refs/heads/master@{#42501}
-
- 18 Jan, 2017 2 commits
-
-
bmeurer authored
Collect Receiver feedback for abstract/strict equality in Ignition and use it in TurboFan to optimize JSEqual and JSStrictEqual operations to pointer equality instead of having to call Equal/StrictEqual builtins. R=jarin@chromium.org BUG=v8:5267,v8:5400 Review-Url: https://codereview.chromium.org/2639883002 Cr-Commit-Position: refs/heads/master@{#42435}
-
bmeurer authored
Use the representation selector to insert appropriate Smi checks for CheckString and CheckInternalizedString when necessary. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2637363002 Cr-Commit-Position: refs/heads/master@{#42434}
-
- 10 Jan, 2017 1 commit
-
-
epertoso authored
BUG= Review-Url: https://codereview.chromium.org/2626603002 Cr-Commit-Position: refs/heads/master@{#42186}
-
- 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}
-
- 02 Jan, 2017 2 commits
-
-
mvstanton authored
R=jarin@chromium.org BUG=v8:5428 Review-Url: https://codereview.chromium.org/2611523002 Cr-Commit-Position: refs/heads/master@{#42012}
-
bmeurer authored
Add machinery to Ignition and TurboFan to collect and consume InternalizedString feedback for abstract and strict equality comparisons. Here we can turn the comparison into a simple pointer equality check. R=jarin@chromium.org BUG=v8:5786 Review-Url: https://codereview.chromium.org/2609013002 Cr-Commit-Position: refs/heads/master@{#42008}
-
- 22 Dec, 2016 2 commits
-
-
bmeurer authored
Introduce a dedicated StringCharCodeAt builtin, that performs the core logic of String.prototype.charCodeAt and lower the StringCharCodeAt simplified operator to a call to this builtin rather than inlining the full functionality into each and every TurboFan graph using it. This can significantly reduce compile time in some cases (i.e. can easily shave off over 50% of compile time overhead for small functions that call String.prototype.charCodeAt). Currently it returns the char code as TaggedSigned value, but middle-term we should make it possible to return untagged values from builtins. R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2600443002 Cr-Commit-Position: refs/heads/master@{#41912}
-
bmeurer authored
Previously String element access and String.prototype.charAt were lowered to a subgraph StringFromCharCode(StringCharCodeAt(s, k)), however that can be fairly expensive both runtime and compile time wise. The dedicated StringCharAt operator is implemented via a call to a builtin that does exactly this. R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2599683002 Cr-Commit-Position: refs/heads/master@{#41909}
-
- 08 Dec, 2016 1 commit
-
-
bmeurer authored
First step towards making arguments and rest parameters optimizable by splitting the allocations for the actual object and the elements. The object allocations can already be escape analyzed this way, the elements would need special support in the deoptimizer and the escape analysis, but that can be done as a second separate step. R=jarin@chromium.org BUG=v8:5726 Review-Url: https://codereview.chromium.org/2557283002 Cr-Commit-Position: refs/heads/master@{#41573}
-
- 30 Nov, 2016 1 commit
-
-
tebbi authored
R=jarin@chromium.org BUG=v8:668517 Review-Url: https://codereview.chromium.org/2536353003 Cr-Commit-Position: refs/heads/master@{#41399}
-
- 24 Nov, 2016 1 commit
-
-
jarin authored
This has two parts: - in redundancy elimination, if we see addition with left hand side that was bounds-checked, we reconnect the lhs to the bounds check if it has better type. - in representation inference, eliminate overflow checks if the input types guarantee no overflow. Review-Url: https://codereview.chromium.org/2527083002 Cr-Commit-Position: refs/heads/master@{#41260}
-
- 22 Nov, 2016 1 commit
-
-
bmeurer authored
TurboFan can indeed comsume NumberOrOddball feedback for abstract relational comparisons, so we should just provide it from Ignition. Drive-by-fix: Add a DCHECK to protect against abstract/strict equality number comparison accidentially utilizing Oddball feedback. BUG=v8:5267,v8:5400 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2518283002 Cr-Commit-Position: refs/heads/master@{#41166}
-
- 21 Nov, 2016 2 commits
-
-
hablich authored
Revert of [turbofan] Introduce LoadFunctionPrototype simplified operator. (patchset #1 id:1 of https://codereview.chromium.org/2517913002/ ) Reason for revert: Blocks roll https://codereview.chromium.org/2517963002/ Original issue's description: > [turbofan] Introduce LoadFunctionPrototype simplified operator. > > Add a LoadFunctionPrototype simplified operator, similar to what > Crankshaft has, that loads the prototype property of a constructor > function. > > R=jarin@chromium.org > BUG=v8:5267 > > Committed: https://crrev.com/1737b2c74b50168e96ef1263def0eb43505fa80c > Cr-Commit-Position: refs/heads/master@{#41127} TBR=jarin@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:5267 Review-Url: https://codereview.chromium.org/2514363002 Cr-Commit-Position: refs/heads/master@{#41141}
-
bmeurer authored
Add a LoadFunctionPrototype simplified operator, similar to what Crankshaft has, that loads the prototype property of a constructor function. R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2517913002 Cr-Commit-Position: refs/heads/master@{#41127}
-
- 16 Nov, 2016 1 commit
-
-
mstarzinger authored
The operator in question is guaranteed to produce a tagged value that is not equal to the-hole, it however does not guarantee the value to be a HeapObject. The correct representation hence is {kTagged}. R=bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-665587 BUG=chromium:665587 Review-Url: https://codereview.chromium.org/2504183002 Cr-Commit-Position: refs/heads/master@{#41032}
-
- 15 Nov, 2016 1 commit
-
-
jarin authored
Reland of [turbofan] Fix deoptimization of boolean bit constants. (patchset #1 id:1 of https://codereview.chromium.org/2495243002) This reverts commit 1c9528c4. BUG=chromium:664490 Review-Url: https://codereview.chromium.org/2503763003 Cr-Commit-Position: refs/heads/master@{#40994}
-
- 14 Nov, 2016 3 commits
-
-
tebbi authored
This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset. SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id: - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray - The SourcePosition of the inlining. Recursively, this yields the full inlining stack. Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions(). If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function. So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer. All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file. At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts. I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases. The following additional changes were necessary: - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id. - The class HPositionInfo was effectively dead code and is now removed. - SourcePosition has new printing and information facilities, including computing a full inlining stack. - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file. - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions(). - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids. - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already). BUG=v8:5432 Review-Url: https://codereview.chromium.org/2451853002 Cr-Commit-Position: refs/heads/master@{#40975}
-
jarin authored
Revert of [turbofan] Fix deoptimization of boolean bit constants. (patchset #1 id:1 of https://codereview.chromium.org/2495243002/ ) Reason for revert: Seems to break GC stress. Original issue's description: > [turbofan] Fix deoptimization of boolean bit constants. > > BUG=chromium:664490 TBR=bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:664490 Review-Url: https://codereview.chromium.org/2502613002 Cr-Commit-Position: refs/heads/master@{#40961}
-
jarin authored
BUG=chromium:664490 Review-Url: https://codereview.chromium.org/2495243002 Cr-Commit-Position: refs/heads/master@{#40951}
-
- 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}
-
- 09 Nov, 2016 1 commit
-
-
bmeurer authored
This adds a new NumberToUint8Clamped simplified operator that does the round ties to even + clamping necessary to store to Uint8ClampedArrays. BUG=v8:4470,v8:5267,v8:5615 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2489563004 Cr-Commit-Position: refs/heads/master@{#40861}
-
- 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}
-
- 03 Nov, 2016 1 commit
-
-
bmeurer authored
For lowering CheckHeapObject, always report TaggedPointer representation and let the RepresentationChanger come up with a reasonable conversion from whatever input representation to TaggedPointer. This way we no longer insert the useless ChangeSomethingToTagged and then check the result for HeapObject, i.e. mostly reduces the amount of useless code being generated. Note there are now two operators ChangeFloat64ToTaggedPointer and the old ChangeFloat64ToTagged, because their semantics different wrt. the strength reduction in the SimplifiedOperatorReducer. Also set the output MachineRepresentation::kTaggedPointer properly in SimplifiedLowering whenever we know that we produce a HeapObject. R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2476593002 Cr-Commit-Position: refs/heads/master@{#40725}
-
- 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}
-