- 18 Nov, 2016 1 commit
-
-
ishell authored
This is a next step towards removing names table from type feedback metadata. BUG=chromium:576312, v8:5561 Review-Url: https://codereview.chromium.org/2507143003 Cr-Commit-Position: refs/heads/master@{#41106}
-
- 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
-
-
jkummerow authored
And decouple hydrogen-instructions.h from code-stubs.h. This avoids all of Crankshaft being recompiled when code-stub-assembler.h changes. Review-Url: https://codereview.chromium.org/2498563002 Cr-Commit-Position: refs/heads/master@{#40912}
-
- 10 Nov, 2016 1 commit
-
-
bmeurer authored
BUG=chromium:664084 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2494703002 Cr-Commit-Position: refs/heads/master@{#40894}
-
- 26 Oct, 2016 3 commits
-
-
bmeurer authored
Revert of [compiler] Properly validate stable map assumption for globals. (patchset #3 id:40001 of https://codereview.chromium.org/2444233004/ ) Reason for revert: Breaks tree: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/8789 Original issue's description: > [compiler] Properly validate stable map assumption for globals. > > For global object property cells, we did not check that the map on the > previous object is still the same for which we actually optimized. So > the optimized code was not in sync with the actual state of the property > cell. When loading from such a global object property cell, Crankshaft > optimizes away any map checks (based on the stable map assumption), > leading to arbitrary memory access in the worst case. > > TurboFan has the same bug for stores, but is safe on loads because we > do appropriate map checks there. However mixing TurboFan and Crankshaft > still exposes the bug. > > R=yangguo@chromium.org > BUG=chromium:659475 TBR=yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:659475 Review-Url: https://codereview.chromium.org/2454513003 Cr-Commit-Position: refs/heads/master@{#40582}
-
bmeurer authored
For global object property cells, we did not check that the map on the previous object is still the same for which we actually optimized. So the optimized code was not in sync with the actual state of the property cell. When loading from such a global object property cell, Crankshaft optimizes away any map checks (based on the stable map assumption), leading to arbitrary memory access in the worst case. TurboFan has the same bug for stores, but is safe on loads because we do appropriate map checks there. However mixing TurboFan and Crankshaft still exposes the bug. R=yangguo@chromium.org BUG=chromium:659475 Review-Url: https://codereview.chromium.org/2444233004 Cr-Commit-Position: refs/heads/master@{#40578}
-
bmeurer authored
The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber conversion (except for the uses in HBranch and HCompareHoleAndBranch, which were confusing and useless anyways), so fix the naming to match that. Also properly integrate the handling of this flag with the existing truncation analysis that is run as part of the representation changes phase (i.e. where we already deal with truncating to int32 and smi). This is done in preparation of allowing Crankshaft to handle any kind of Oddball in the ToNumber truncation, instead of just undefined for truncation ToNumber and undefined or boolean for ToInt32. It also helps to make Crankshaft somewhat more compatible with the (saner) implementation in TurboFan. R=yangguo@chromium.org BUG=v8:5400 Review-Url: https://codereview.chromium.org/2449353002 Cr-Commit-Position: refs/heads/master@{#40577}
-
- 18 Oct, 2016 1 commit
-
-
bmeurer authored
These intrinsics are unused now, and so we can drop all the code in fullcodegen and Crankshaft that deals with those. TurboFan and Ignition never tried to optimize those. R=mstarzinger@chromium.org BUG=v8:5049 Review-Url: https://codereview.chromium.org/2427673004 Cr-Commit-Position: refs/heads/master@{#40401}
-
- 12 Oct, 2016 3 commits
-
-
ishell authored
... because the latter automatically respects the desired calling convention. BUG=v8:5408 Review-Url: https://codereview.chromium.org/2391043005 Cr-Commit-Position: refs/heads/master@{#40223}
-
ishell authored
Thus the parameter indices defined in respective CallInterfaceDescriptor can be used for querying parameters. BUG= Review-Url: https://codereview.chromium.org/2389133007 Cr-Commit-Position: refs/heads/master@{#40222}
-
ishell authored
BUG=chromium:645438 Review-Url: https://codereview.chromium.org/2412853002 Cr-Commit-Position: refs/heads/master@{#40202}
-
- 07 Oct, 2016 3 commits
-
-
Mike Stanton authored
(GcStress failure was unrelated.) At one time, we hoped to generate the same code for different native contexts. But in truth, much performance comes from optimizing on the native context. Now we abandon this pathway. BUG= TBR=bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true Review URL: https://codereview.chromium.org/2402663002 . Cr-Commit-Position: refs/heads/master@{#40086}
-
mvstanton authored
Revert of [turbofan] Discard the shared code entry in the optimized code map. (patchset #3 id:40001 of https://codereview.chromium.org/2401653002/ ) Reason for revert: Possible GCSTRESS failure, investigating. Original issue's description: > [turbofan] Discard the shared code entry in the optimized code map. > > At one time, we hoped to generate the same code for different > native contexts. But in truth, much performance comes from optimizing > on the native context. Now we abandon this pathway. > > BUG= > > Committed: https://crrev.com/55af3c44c99a6e4cd6d53df775023d760ad2b2c3 > Cr-Commit-Position: refs/heads/master@{#40079} TBR=mstarzinger@chromium.org,ishell@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2403453002 Cr-Commit-Position: refs/heads/master@{#40081}
-
mvstanton authored
At one time, we hoped to generate the same code for different native contexts. But in truth, much performance comes from optimizing on the native context. Now we abandon this pathway. BUG= Review-Url: https://codereview.chromium.org/2401653002 Cr-Commit-Position: refs/heads/master@{#40079}
-
- 06 Oct, 2016 2 commits
-
-
ishell authored
... because the latter automatically respects the desired calling convention. BUG=v8:5408 Review-Url: https://codereview.chromium.org/2398683004 Cr-Commit-Position: refs/heads/master@{#40025}
-
ishell authored
... because the latter automatically respects the desired calling convention. BUG=v8:5408 Review-Url: https://codereview.chromium.org/2396023002 Cr-Commit-Position: refs/heads/master@{#40023}
-
- 22 Sep, 2016 1 commit
-
-
ishell authored
BUG=v8:5407 Review-Url: https://codereview.chromium.org/2353303002 Cr-Commit-Position: refs/heads/master@{#39613}
-
- 20 Sep, 2016 3 commits
-
-
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}
-
ishell authored
... because the latter automatically respects the desired calling convention. BUG=v8:5407 Review-Url: https://codereview.chromium.org/2350423002 Cr-Commit-Position: refs/heads/master@{#39543}
-
ishell authored
... because the latter automatically respects the desired calling convention. BUG=v8:5407 Review-Url: https://codereview.chromium.org/2358533002 Cr-Commit-Position: refs/heads/master@{#39535}
-
- 06 Sep, 2016 1 commit
-
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. The (last remaining) offending include path is: ast.h <- liveedit.h <- debug.h <- src/x64/assembler-whatever-port-inl.h <- src/macro-assembler.h <- everything possible With this CL, the rebuild steps needed when touching ast-value-factory.h drops from 365 to 181. BUG=v8:5294 TBR=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2316443002 Cr-Commit-Position: refs/heads/master@{#39195}
-
- 01 Sep, 2016 1 commit
-
-
mvstanton authored
We really just need representation information from the CallInterfaceDescriptor. This change allows us to keep that, get away from Type, and it's Zone-based allocation as well. BUG= Review-Url: https://codereview.chromium.org/2301883002 Cr-Commit-Position: refs/heads/master@{#39105}
-
- 31 Aug, 2016 1 commit
-
-
bmeurer authored
When we try to further fold previously folded allocations in Crankshaft GVN we don't properly transform the allocations involved, which causes the mechanism to leave holes in the new/old space (and thereby violate the iterability property of the new/old space). BUG=chromium:621868 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2297983003 Cr-Commit-Position: refs/heads/master@{#39040}
-
- 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}
-
- 13 Jul, 2016 1 commit
-
-
ishell authored
[ic] Initialize feedback slots for LoadGlobalIC in Runtime::kDeclareGlobals when possible to avoid misses. BUG=chromium:576312 Review-Url: https://codereview.chromium.org/2107193002 Cr-Commit-Position: refs/heads/master@{#37709}
-
- 30 Jun, 2016 2 commits
-
-
bmeurer authored
These are no longer used, except in tests that test these intrinsics. R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2114613002 Cr-Commit-Position: refs/heads/master@{#37432}
-
yangguo authored
R=mstarzinger@chromium.org BUG=v8:5117 Review-Url: https://codereview.chromium.org/2109773004 Cr-Commit-Position: refs/heads/master@{#37426}
-
- 27 Jun, 2016 1 commit
-
-
ishell authored
The global object can be loaded from the native context and the name can be loaded in the type feedback metadata. BUG=chromium:576312 Review-Url: https://codereview.chromium.org/2096653003 Cr-Commit-Position: refs/heads/master@{#37278}
-
- 23 Jun, 2016 1 commit
-
-
adamk authored
It appears to have been dropped accidentally as part of 1150092b's removal of strong mode for binary ops. Review-Url: https://codereview.chromium.org/2092493002 Cr-Commit-Position: refs/heads/master@{#37229}
-
- 20 Jun, 2016 1 commit
-
-
bmeurer authored
Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan operator based on that, similar to what we do for Float64Cos and Float64Sin. Rewrite Math.tan() as TurboFan builtin and use those operators to also inline Math.tan() into optimized TurboFan functions. Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only the %ConstructDouble runtime entry for writing tests. BUG=v8:5086,v8:5126 R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2083453002 Cr-Commit-Position: refs/heads/master@{#37087}
-
- 17 Jun, 2016 1 commit
-
-
bmeurer authored
Import base::ieee754::cos() and base::ieee754::sin() from fdlibm and introduce Float64Cos and Float64Sin TurboFan operator based on that, similar to what we do for Float64Log. Rewrite Math.cos() and Math.sin() as TurboFan builtins and use those operators to also inline Math.cos() and Math.sin() into optimized TurboFan functions. CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel R=mvstanton@chromium.org BUG=v8:5086,v8:5118 Review-Url: https://codereview.chromium.org/2073123002 Cr-Commit-Position: refs/heads/master@{#37072}
-
- 08 Jun, 2016 2 commits
-
-
verwaest authored
This speeds up .bind by >10x as measured by function f(a,b,c) {} for (var i = 0; i < 10000000; i++) { f.bind(1); // or more arguments. } (Uses hydrogen-stubs rather than TF due to var-args + possible runtime fallback, which is still unsupported in TF.) BUG= Review-Url: https://codereview.chromium.org/2044113002 Cr-Commit-Position: refs/heads/master@{#36817}
-
bmeurer authored
In Crankshaft we don't know reliably know that an HAdd might not turn into a string addition later (via deoptimization), so we cannot set the HValue::kAllowUndefinedAsNaN flag on the HAdd instruction in those cases. It doesn't seem to affect performance if we just remove the flag completely from the HAdd instruction, so let's stick to that approach for now. R=jarin@chromium.org BUG=v8:5074 Review-Url: https://codereview.chromium.org/2048643002 Cr-Commit-Position: refs/heads/master@{#36805}
-
- 01 Jun, 2016 1 commit
-
-
bmeurer authored
We may set a proper HType on HCall or HCallWithDescriptor nodes, for example for the InstanceOfStub, where we know that the result is a boolean. So HCall and HCallWithDescriptor shall not ignore the type, but pass through whatever we set (defaulting to Tagged). R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2024033005 Cr-Commit-Position: refs/heads/master@{#36630}
-
- 30 May, 2016 2 commits
-
-
mvstanton authored
In Crankshaft, we would install special ICs that didn't need a vector and slot in the MEGAMORPHIC case. This optimization limits our hand against future improvements. BUG= Review-Url: https://codereview.chromium.org/2019313003 Cr-Commit-Position: refs/heads/master@{#36597}
-
hpayer authored
BUG=chromium:615770 LOG=N Review-Url: https://codereview.chromium.org/2022743002 Cr-Commit-Position: refs/heads/master@{#36579}
-
- 17 May, 2016 1 commit
-
-
bmeurer authored
This adds back the instanceof operator support in the backends and introduces a @@hasInstance protector cell on the isolate that guards the fast path for the InstanceOfStub. This way we recover the ~10% regression on Octane EarleyBoyer in Crankshaft and greatly improve TurboFan and Ignition performance of instanceof. R=ishell@chromium.org TBR=hpayer@chromium.org,rossberg@chromium.org BUG=chromium:597249, v8:4447 LOG=n Review-Url: https://codereview.chromium.org/1980483003 Cr-Commit-Position: refs/heads/master@{#36275}
-
- 10 May, 2016 1 commit
-
-
hpayer authored
The new allocation folding implementation avoids fragmentation between folded allocation. As a consequence, our heap will always be iterable i.e. we do not have to perform a garbage collection before iterating the heap. BUG=chromium:580959 LOG=n Review-Url: https://codereview.chromium.org/1899813003 Cr-Commit-Position: refs/heads/master@{#36133}
-
- 20 Apr, 2016 1 commit
-
-
mbrandy authored
Port 978ad03b Original commit message: Fix and re-enable the flexible representation for Math.floor (which is used to implement Math.ceil) and Math.round, which allows Math.floor and Math.round to return double results instead of int32, and therefore allows values outside the int32 range, especially -0 is now a valid result, which doesn't deopt. Also port this feature to x64 and ia32 when the CPU supports the SSE4.1 extension. This addresses all the known deoptimization loops related to Math.round in the Kraken benchmark suite, and seems to also address most of the deoptimization loops related to Math.floor in the Oort Online benchmark. Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv optimization that caused the initial revert of the feature (for arm64 only back then). R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:476477,v8:2890,v8:4059 LOG=n Review URL: https://codereview.chromium.org/1839643007 Cr-Commit-Position: refs/heads/master@{#35659}
-
- 19 Apr, 2016 1 commit
-
-
adamk authored
Now that all 'const' declarations are of the ES2015 variety, the only use of CONST_LEGACY is for function name bindings in sloppy mode named function expressions. This patch aims to delete all code meant to handle other cases, which mostly had to do with hole initialization/hole checks. Since function name bindings are initialized at entry to a function, it's impossible to ever observe one in an uninitialized state. To simplify the patch further, it removes the `IMPORT` VariableMode, as it's not likely to be needed (IMPORT is identical to CONST for the purpose of VariableMode). Review URL: https://codereview.chromium.org/1895973002 Cr-Commit-Position: refs/heads/master@{#35632}
-