- 12 Apr, 2017 2 commits
-
-
bmeurer authored
Add the notion of reliable vs. unreliable receiver map information to the NodeProperties::InferReceiverMaps machinery. The information is considered reliable here if the maps are known to be valid based on the effect chain, and unreliable if there was a side-effect in between that might have changed the receiver map. Use this unreliable information for Array.prototype.push, guarded by either stability dependencies or map checks, which might present a potential deoptimization loop, which is very unlikely, but still needs fixing in the future. This is important to optimize calls to push even in cases like this array.push(something.func()); where we have a side-effect (the call to something.func) between the load of array.push and the actual call. R=jarin@chromium.org BUG=v8:5267,v8:6241 Review-Url: https://codereview.chromium.org/2812233002 Cr-Commit-Position: refs/heads/master@{#44595}
-
Sathya Gunasekaran authored
This change mirrors the semantics for derived class constructors. This change doesn't affect non class constructors. This change could potentially break web compat. More details: https://github.com/tc39/ecma262/pull/469 Bug=v8:5536 Change-Id: I519599949523733332d0b35e4f8d9ecb01cac495 Reviewed-on: https://chromium-review.googlesource.com/461225Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#44594}
-
- 30 Mar, 2017 1 commit
-
-
bmeurer authored
The inlining logic doesn't account for the fact that the derived constructor could return a primitive, thus leaking the implicit receiver (which is the hole). R=jarin@chromium.org BUG=chromium:706642 Review-Url: https://codereview.chromium.org/2788603002 Cr-Commit-Position: refs/heads/master@{#44264}
-
- 27 Mar, 2017 1 commit
-
-
Wiktor Garbacz authored
A step towards removing isolate from ParseInfo. Removing isolate from ParseInfo will make it easier to create and execute parse tasks on background threads. BUG=v8:6093 Change-Id: I25b23b3bf64502f84c28ce688ad2997c9665a069 Reviewed-on: https://chromium-review.googlesource.com/458003Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#44140}
-
- 17 Mar, 2017 1 commit
-
-
Michael Starzinger authored
This is a first stab at extending the existing early lowering approach to property access operations. Currently we only handle the case where named property loads are lowered to a soft deoptimize operation, due to insufficient type feedback. R=jarin@chromium.org Change-Id: I779ffb99978023237da5ad9eaf0241fe74243882 Reviewed-on: https://chromium-review.googlesource.com/456316 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#43899}
-
- 15 Mar, 2017 1 commit
-
-
Michael Starzinger authored
This changes the IR to no longer require single {IfSuccess} projection nodes unless there is a corresponding {IfException} node that links the potentially throwing call to an exception handler. This reduces graph size as well as compilation time when exception handlers aren't present. The new invariant for potentially throwing nodes is: Nodes that can potentially throw either have both IfSuccess/IfException projections as the only control uses and no direct control uses, or no projections at all and solely direct control uses. R=jarin@chromium.org Change-Id: I3d9cd816d74ad5af13e0673da7ec7a98f1ecdc7e Reviewed-on: https://chromium-review.googlesource.com/449715 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#43814}
-
- 02 Mar, 2017 1 commit
-
-
Michael Starzinger authored
This unifies the search for a potential {IfException} projection with the existing predicate on {NodeProperties} used by the rest of the system. Also contains a related drive-by change to graph builders. This is in preparation of eliding {IfSuccess} projections when possible. R=jarin@chromium.org Change-Id: I8ba0ae9e9fdb69a77bce01578200ceea434535f7 Reviewed-on: https://chromium-review.googlesource.com/448039Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43540}
-
- 20 Feb, 2017 1 commit
-
-
bmeurer authored
Unify the three different implementations of InferReceiverMaps, which were basically copy&paste with slightly different optimizations applied later into a single NodeProperties::InferReceiverMaps helper, which also returns a ZoneHandleSet of maps, rather than only a single map. BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2703133003 Cr-Commit-Position: refs/heads/master@{#43318}
-
- 17 Feb, 2017 1 commit
-
-
bmeurer authored
In the JSInliner we shouldn't introduce JSConvertReceiver needlessly if the input is already known to produce a receiver, i.e. if it's a JSCreate or something like that. BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2697513010 Cr-Commit-Position: refs/heads/master@{#43273}
-
- 13 Feb, 2017 1 commit
-
-
Michael Starzinger authored
This adds support for deoptimizing into the JSConstructStub after the receiver instantiation but before the actual constructor invocation. Such a deoptimization point is needed for cases where instantiation might be observed (e.g. when new.target is a proxy) and hence might trigger a deopt. We use this new deoptimization point for the "after" frame-state the inliner attaches to {JSCreate} nodes being inserted when constructor calls are being inlined. R=jarin@chromium.org TEST=mjsunit/regress/regress-5638b BUG=v8:5638 Change-Id: I7c72c807ee8fb76d12e0e9ccab86d970ab1a0efd Reviewed-on: https://chromium-review.googlesource.com/440125Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43149}
-
- 10 Feb, 2017 1 commit
-
-
rmcilroy authored
In order to allow parallel compilation of eager inner functions, we need to seperate the zone used for parsing (which will be shared between all the parallel compile jobs) and the zone used for compilation. This CL changes CompilationInfo to require a zone (which can be different from the zone in ParseInfo). We then seal the ParseInfo zone after parsing and analysis is done to prevent any further allocation in that zone, so that it can be shared (read-only) with the parallel compile jobs. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2645403002 Cr-Commit-Position: refs/heads/master@{#43089}
-
- 07 Feb, 2017 8 commits
-
-
hablich authored
Reland of land: [Parse] ParseInfo owns the parsing Zone. (patchset #1 id:1 of https://codereview.chromium.org/2683733002/ ) Reason for revert: False alarm, bot hiccup Original issue's description: > Revert of Reland: [Parse] ParseInfo owns the parsing Zone. (patchset #7 id:140001 of https://codereview.chromium.org/2632123006/ ) > > Reason for revert: > Speculative revert because of revert needed for https://codereview.chromium.org/2632123006 > > Original issue's description: > > Reland: [Parse] ParseInfo owns the parsing Zone. > > > > Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is > > in preperation for enabling background compilation jobs for inner functions > > share the AST in the outer-function's parse zone memory (read-only), with the > > and zone being released when all compilation jobs have completed. > > > > BUG=v8:5203,v8:5215 > > > > Review-Url: https://codereview.chromium.org/2632123006 > > Cr-Original-Commit-Position: refs/heads/master@{#42993} > > Committed: https://chromium.googlesource.com/v8/v8/+/14fb337200d5da09c77438ddd40bea935b1dc823 > > Review-Url: https://codereview.chromium.org/2632123006 > > Cr-Commit-Position: refs/heads/master@{#42996} > > Committed: https://chromium.googlesource.com/v8/v8/+/9e7d5a6065470ca03411d4c8dbc61d1be5c3f84a > > TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@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:5203,v8:5215 > > Review-Url: https://codereview.chromium.org/2683733002 > Cr-Commit-Position: refs/heads/master@{#43008} > Committed: https://chromium.googlesource.com/v8/v8/+/9fe08ec067051c5b46e694568bd01c6dba44cc4d TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@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:5203,v8:5215 Review-Url: https://codereview.chromium.org/2679303003 Cr-Commit-Position: refs/heads/master@{#43015}
-
hablich authored
Revert of Reland: [Parse] ParseInfo owns the parsing Zone. (patchset #7 id:140001 of https://codereview.chromium.org/2632123006/ ) Reason for revert: Speculative revert because of revert needed for https://codereview.chromium.org/2632123006 Original issue's description: > Reland: [Parse] ParseInfo owns the parsing Zone. > > Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is > in preperation for enabling background compilation jobs for inner functions > share the AST in the outer-function's parse zone memory (read-only), with the > and zone being released when all compilation jobs have completed. > > BUG=v8:5203,v8:5215 > > Review-Url: https://codereview.chromium.org/2632123006 > Cr-Original-Commit-Position: refs/heads/master@{#42993} > Committed: https://chromium.googlesource.com/v8/v8/+/14fb337200d5da09c77438ddd40bea935b1dc823 > Review-Url: https://codereview.chromium.org/2632123006 > Cr-Commit-Position: refs/heads/master@{#42996} > Committed: https://chromium.googlesource.com/v8/v8/+/9e7d5a6065470ca03411d4c8dbc61d1be5c3f84a TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@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:5203,v8:5215 Review-Url: https://codereview.chromium.org/2683733002 Cr-Commit-Position: refs/heads/master@{#43008}
-
ishell@chromium.org authored
BUG= Change-Id: I31b8da09f4728d55c2da91966edcad49528b554b Reviewed-on: https://chromium-review.googlesource.com/439146Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#43003}
-
ishell@chromium.org authored
... and TypeFeedbackMetadata to FeedbackMetadata. BUG= Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c Reviewed-on: https://chromium-review.googlesource.com/439244 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#42999}
-
rmcilroy authored
Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is in preperation for enabling background compilation jobs for inner functions share the AST in the outer-function's parse zone memory (read-only), with the and zone being released when all compilation jobs have completed. BUG=v8:5203,v8:5215 Review-Url: https://codereview.chromium.org/2632123006 Cr-Original-Commit-Position: refs/heads/master@{#42993} Committed: https://chromium.googlesource.com/v8/v8/+/14fb337200d5da09c77438ddd40bea935b1dc823 Review-Url: https://codereview.chromium.org/2632123006 Cr-Commit-Position: refs/heads/master@{#42996}
-
jochen authored
Revert of Reland: [Parse] ParseInfo owns the parsing Zone. (patchset #6 id:120001 of https://codereview.chromium.org/2632123006/ ) Reason for revert: doesn't compile on ToT Original issue's description: > Reland: [Parse] ParseInfo owns the parsing Zone. > > Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is > in preperation for enabling background compilation jobs for inner functions > share the AST in the outer-function's parse zone memory (read-only), with the > and zone being released when all compilation jobs have completed. > > BUG=v8:5203,v8:5215 > > Review-Url: https://codereview.chromium.org/2632123006 > Cr-Commit-Position: refs/heads/master@{#42993} > Committed: https://chromium.googlesource.com/v8/v8/+/14fb337200d5da09c77438ddd40bea935b1dc823 TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@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:5203,v8:5215 Review-Url: https://codereview.chromium.org/2685543003 Cr-Commit-Position: refs/heads/master@{#42994}
-
rmcilroy authored
Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is in preperation for enabling background compilation jobs for inner functions share the AST in the outer-function's parse zone memory (read-only), with the and zone being released when all compilation jobs have completed. BUG=v8:5203,v8:5215 Review-Url: https://codereview.chromium.org/2632123006 Cr-Commit-Position: refs/heads/master@{#42993}
-
mstarzinger authored
This correctly marks the {JSCreate} operator as potentially throwing, since it might trigger a property access of the 'prototype' property during instantiation. This is observable, can throw (not kNoThrow), might have side-effects (not kNoWrite), or even trigger a lazy deopt event (not kNoDeopt). The inlining logic has been adapted to wire up control projections accordingly. Note that this does not yet take care of the "after" frame-state which is associated with the {JSCreate} node introduced by the inliner. We still might re-evaluate the property access upon lazy deoptimization. R=bmeurer@chromium.org TEST=mjsunit/regress/regress-5638 BUG=v8:5638 Review-Url: https://codereview.chromium.org/2671203003 Cr-Commit-Position: refs/heads/master@{#42981}
-
- 06 Feb, 2017 1 commit
-
-
mstarzinger authored
This adapts the inlining logic to allow for inlining based solely on a statically known underlying SharedFunctionInfo instead of a concrete closure of the call target. In cases where the closure is known, its bound context is constant promoted just as before. In the new cases where only the SFI for an entire class of closures is known, we use the dynamic SSA-value of the bound context. R=bmeurer@chromium.org BUG=v8:2206 Review-Url: https://codereview.chromium.org/2626783003 Cr-Commit-Position: refs/heads/master@{#42968}
-
- 02 Feb, 2017 1 commit
-
-
mstarzinger authored
The operator in question does not call arbitrary JavaSciprt, nor throw, nor trigger a lazy deoptimization. Nodes hence do not need a frame-state representing the "after" state of the operation. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2672763002 Cr-Commit-Position: refs/heads/master@{#42891}
-
- 01 Feb, 2017 2 commits
-
-
petermarshall authored
Review-Url: https://codereview.chromium.org/2666783007 Cr-Commit-Position: refs/heads/master@{#42847}
-
petermarshall authored
Review-Url: https://codereview.chromium.org/2662263002 Cr-Commit-Position: refs/heads/master@{#42836}
-
- 24 Jan, 2017 1 commit
-
-
rmcilroy authored
Speculative reason for issue 684481. BUG=chromium:684481 TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org, Original issue's description: > [Parse] ParseInfo owns the parsing Zone. > > Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is > in preperation for enabling background compilation jobs for inner functions > share the AST in the outer-function's parse zone memory (read-only), with the > and zone being released when all compilation jobs have completed. > > BUG=v8:5203, v8:5215 > Review-Url: https://codereview.chromium.org/2632123006 > Cr-Commit-Position: refs/heads/master@{#42562} > Committed: https://chromium.googlesource.com/v8/v8/+/4b0101d369af121a6daf5e5c731cb939c026d526 Review-Url: https://codereview.chromium.org/2648383005 Cr-Commit-Position: refs/heads/master@{#42633}
-
- 20 Jan, 2017 3 commits
-
-
rmcilroy authored
Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is in preperation for enabling background compilation jobs for inner functions share the AST in the outer-function's parse zone memory (read-only), with the and zone being released when all compilation jobs have completed. BUG=v8:5203,v8:5215 Review-Url: https://codereview.chromium.org/2632123006 Cr-Original-Commit-Position: refs/heads/master@{#42539} Committed: https://chromium.googlesource.com/v8/v8/+/839b06b64fcaaaa9cceb2c3fd8fd5429e2932095 Review-Url: https://codereview.chromium.org/2632123006 Cr-Commit-Position: refs/heads/master@{#42562}
-
rmcilroy authored
Revert of [Parse] ParseInfo owns the parsing Zone. (patchset #4 id:60001 of https://codereview.chromium.org/2632123006/ ) Reason for revert: Crashes on Windows in: CompilerDispatcherJobTest.CompileFailureToFinalize CompilerDispatcherJobTest.ScopeChain Original issue's description: > [Parse] ParseInfo owns the parsing Zone. > > Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is > in preperation for enabling background compilation jobs for inner functions > share the AST in the outer-function's parse zone memory (read-only), with the > and zone being released when all compilation jobs have completed. > > BUG=v8:5203,v8:5215 > > Review-Url: https://codereview.chromium.org/2632123006 > Cr-Commit-Position: refs/heads/master@{#42539} > Committed: https://chromium.googlesource.com/v8/v8/+/839b06b64fcaaaa9cceb2c3fd8fd5429e2932095 TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5203,v8:5215 Review-Url: https://codereview.chromium.org/2645613008 Cr-Commit-Position: refs/heads/master@{#42542}
-
rmcilroy authored
Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is in preperation for enabling background compilation jobs for inner functions share the AST in the outer-function's parse zone memory (read-only), with the and zone being released when all compilation jobs have completed. BUG=v8:5203,v8:5215 Review-Url: https://codereview.chromium.org/2632123006 Cr-Commit-Position: refs/heads/master@{#42539}
-
- 18 Jan, 2017 1 commit
-
-
epertoso authored
BUG= Review-Url: https://codereview.chromium.org/2635243002 Cr-Commit-Position: refs/heads/master@{#42439}
-
- 11 Jan, 2017 1 commit
-
-
mstarzinger authored
This changes the BytecodeGraphBuilder interface to make the fact that graph construction is independent of a closure explicit. A valid graph can be constructed by providing only the pair of statically known values for SharedFunctionInfo and TypeFeedbackVector. This is in preparation of inlining based on the SharedFunctionInfo. R=jarin@chromium.org BUG=v8:2206 Review-Url: https://codereview.chromium.org/2626623002 Cr-Commit-Position: refs/heads/master@{#42224}
-
- 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 1 commit
-
-
bmeurer authored
Store maps on the CheckMaps operator instead of burning inputs for the individual maps. Use the same data structure (the ZoneHandleSet) in the LoadElimination to track multiple maps per object. BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2431563002 Cr-Commit-Position: refs/heads/master@{#42010}
-
- 24 Nov, 2016 1 commit
-
-
bmeurer authored
The deprecated pipeline is used for asm.js only, where we forcibly disable inlining anyways (for performance reasons), so inlining via the AstGraphBuilder is essentially dead code by now, thus there's no point in trying to keep that around in the code base. Also nuke the test-run-inlining.cc file, which would require some heavy surgery (for probably little benefit), and move the useful tests for mjsunit tests instead. BUG=v8:2206,v8:5657 R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2527053002 Cr-Commit-Position: refs/heads/master@{#41245}
-
- 23 Nov, 2016 1 commit
-
-
bmeurer authored
The AstGraphBuilder pipeline is only used for asm.js now, so the whole type feedback mechanism is essentially dead code currently, thus we better nuke it. BUG=v8:5267,v8:5657 Review-Url: https://codereview.chromium.org/2523953002 Cr-Commit-Position: refs/heads/master@{#41201}
-
- 14 Nov, 2016 1 commit
-
-
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}
-
- 11 Nov, 2016 1 commit
-
-
bmeurer authored
The contract for TurboFan is that we use NumberConstants for any kind of number value until the representation selection picks concrete representations, i.e. Int32Constant or Float64Constant. We will soon be able to also guard this contract with DCHECKs. BUG=v8:5267 R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2499573002 Cr-Commit-Position: refs/heads/master@{#40908}
-
- 07 Nov, 2016 1 commit
-
-
bmeurer authored
We need to rename the receiver on CheckHeapObject, because we don't canonicalize numbers in SignedSmall range, and thus we the representation selection can hand out TaggedSigned values for receiver uses, even though we checked for TaggedPointerness first. Note that this is rather hacky and just intended to fix the bug ASAP. We need to think about how to deal with representations in earlier compilation stages. BUG=chromium:662410 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2485563002 Cr-Commit-Position: refs/heads/master@{#40792}
-
- 03 Nov, 2016 1 commit
-
-
leszeks authored
This removes the first stack check in inlined functions in the bytecode graph builder, to match the behaviour of the AST graph builder. I measure a ~1% statistically significant (p < 0.01) improvement on Mandreel with --ignition-staging --turbo (on my x64 machine, YMMV). Review-Url: https://codereview.chromium.org/2392333002 Cr-Commit-Position: refs/heads/master@{#40715}
-
- 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}
-