- 07 Sep, 2016 1 commit
-
-
shiyu.zhang authored
This is a complement to https://codereview.chromium.org/2281523002. The patch above reversed the order of nodes with same latency, which caused bench_copy.js 4% regression and bench_skinning.js 5% regression on Atom when enabling '--turbo-instruction-scheduling' flag according to our observation. We submit this patch to sort the nodes with same latency in original order. It aligns with instruction scheduling logic before the patch above and fixes these regression. BUG= Review-Url: https://codereview.chromium.org/2284373002 Cr-Commit-Position: refs/heads/master@{#39228}
-
- 25 Aug, 2016 4 commits
-
-
baptiste.afsa authored
This significantly speed-up the instruction scheduler when the ready list contains a large number of instruction. R=jarin@chromium.org, bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2281523002 Cr-Commit-Position: refs/heads/master@{#38919}
-
jarin authored
This reverts commit a55fdb1e, relands https://codereview.chromium.org/2266823002/. BUG=chromium:638132 Review-Url: https://codereview.chromium.org/2277283002 Cr-Commit-Position: refs/heads/master@{#38917}
-
bmeurer authored
Revert of [turbofan] Insert dummy values when changing from None type. (patchset #5 id:80001 of https://codereview.chromium.org/2266823002/ ) Reason for revert: Octane/Mandreel aborts with an exception now: TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function Original issue's description: > [turbofan] Insert dummy values when changing from None type. > > Currently we choose the MachineRepresentation::kNone representation for > values of Type::None, and when converting values from the kNone representation > we use "impossible" conversions that will crash at runtime. This > assumes that the impossible conversions should never be hit (the only > way to produce the impossible values is to perform an always-failing > runtime check on a value, such as Smi-checking a string). Note that > this assumes that the runtime check is executed before the impossible > convesrion. > > Introducing BitwiseOr type feedback broke this in two ways: > > - we always pick Word32 representation for bitwise-or, so the > impossible conversion does not trigger (it only triggers with > None representation), and we could end up with unsupported > conversions from Word32. > > - even if we inserted impossible conversions, they are pure conversions. > Since untagging, bitwise-or operations are also pure, we could hoist > all these before the smi check of the inputs and we could hit the > impossible conversions before we get to the smi check. > > This CL addresses this by just providing dummy values for conversions > from the Type::None type. It also removes the impossible-to-* conversions. > > BUG=chromium:638132 > > Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe > Cr-Commit-Position: refs/heads/master@{#38883} TBR=mstarzinger@chromium.org,jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:638132 Review-Url: https://codereview.chromium.org/2280613002 Cr-Commit-Position: refs/heads/master@{#38893}
-
jarin authored
Currently we choose the MachineRepresentation::kNone representation for values of Type::None, and when converting values from the kNone representation we use "impossible" conversions that will crash at runtime. This assumes that the impossible conversions should never be hit (the only way to produce the impossible values is to perform an always-failing runtime check on a value, such as Smi-checking a string). Note that this assumes that the runtime check is executed before the impossible convesrion. Introducing BitwiseOr type feedback broke this in two ways: - we always pick Word32 representation for bitwise-or, so the impossible conversion does not trigger (it only triggers with None representation), and we could end up with unsupported conversions from Word32. - even if we inserted impossible conversions, they are pure conversions. Since untagging, bitwise-or operations are also pure, we could hoist all these before the smi check of the inputs and we could hit the impossible conversions before we get to the smi check. This CL addresses this by just providing dummy values for conversions from the Type::None type. It also removes the impossible-to-* conversions. BUG=chromium:638132 Review-Url: https://codereview.chromium.org/2266823002 Cr-Commit-Position: refs/heads/master@{#38883}
-
- 15 Aug, 2016 1 commit
-
-
baptiste.afsa authored
R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2193063003 Cr-Commit-Position: refs/heads/master@{#38632}
-
- 25 Jul, 2016 1 commit
-
-
jarin authored
BUG=chromium:630611 Review-Url: https://codereview.chromium.org/2177483002 Cr-Commit-Position: refs/heads/master@{#37994}
-
- 01 Jul, 2016 1 commit
-
-
bmeurer authored
Import fdlibm versions of acos, acosh, asin and asinh, which are more precise and produce the same result across platforms (we were using libm versions for asin and acos so far, where both speed and precision depended on the operating system so far). Introduce appropriate TurboFan operators for these functions and use them both for inlining and for the generic builtin. Also migrate the Math.imul and Math.fround builtins to TurboFan builtins to ensure that their behavior is always exactly the same as the inlined TurboFan version (i.e. C++ truncation semantics for double to float don't necessarily meet the JavaScript semantics). For completeness, also migrate Math.sign, which can even get some nice love in TurboFan. Drive-by-fix: Some alpha-sorting on the Math related functions, and cleanup the list of Math intrinsics that we have to export via the native context currently. BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172 TBR=rossberg@chromium.org R=franzih@chromium.org Review-Url: https://codereview.chromium.org/2116753002 Cr-Commit-Position: refs/heads/master@{#37476}
-
- 30 Jun, 2016 1 commit
-
-
mvstanton authored
BUG=v8:5086 Review-Url: https://codereview.chromium.org/2083573002 Cr-Commit-Position: refs/heads/master@{#37424}
-
- 28 Jun, 2016 1 commit
-
-
bmeurer authored
Introduce a new machine operator Float64Pow that for now is backed by the existing MathPowStub to start the unification of Math.pow, and at the same time address the main performance issue that TurboFan still has with the imaging-darkroom benchmark in Kraken. Also migrate the Math.pow builtin itself to a TurboFan builtin and remove a few hundred lines of hand-written platform code for special handling of the fullcodegen Math.pow version. BUG=v8:3599,v8:5086,v8:5157 Review-Url: https://codereview.chromium.org/2103733003 Cr-Commit-Position: refs/heads/master@{#37323}
-
- 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 3 commits
-
-
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}
-
mvstanton authored
BUG=v8:5103 Review-Url: https://codereview.chromium.org/2068743002 Cr-Commit-Position: refs/heads/master@{#37058}
-
bmeurer authored
Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp TurboFan operator based on that, similar to what we do for Float64Log. Rewrite Math.exp() as TurboFan builtin and use that operator to also inline Math.exp() into optimized TurboFan functions. CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108,chromium:620786 R=mvstanton@chromium.org Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260 Review-Url: https://codereview.chromium.org/2077533002 Cr-Original-Commit-Position: refs/heads/master@{#37037} Cr-Commit-Position: refs/heads/master@{#37047}
-
- 16 Jun, 2016 3 commits
-
-
machenbach authored
Revert of [builtins] Introduce proper Float64Exp operator. (patchset #5 id:80001 of https://codereview.chromium.org/2077533002/ ) Reason for revert: [Sheriff] Leads to some different rounding as it seems in some audio layout tests. Please rebase upstream first if intended: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/7508 Original issue's description: > [builtins] Introduce proper Float64Exp operator. > > Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp > TurboFan operator based on that, similar to what we do for Float64Log. > Rewrite Math.exp() as TurboFan builtin and use that operator to also > inline Math.exp() into optimized TurboFan functions. > > BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108 > R=mvstanton@chromium.org > > Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260 > Cr-Commit-Position: refs/heads/master@{#37037} TBR=mvstanton@chromium.org,ahaas@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:3266,v8:3468,v8:3493,v8:5086,v8:5108 Review-Url: https://codereview.chromium.org/2070813002 Cr-Commit-Position: refs/heads/master@{#37039}
-
bmeurer authored
Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp TurboFan operator based on that, similar to what we do for Float64Log. Rewrite Math.exp() as TurboFan builtin and use that operator to also inline Math.exp() into optimized TurboFan functions. BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108 R=mvstanton@chromium.org Review-Url: https://codereview.chromium.org/2077533002 Cr-Commit-Position: refs/heads/master@{#37037}
-
mvstanton authored
BUG=v8:5095 Review-Url: https://codereview.chromium.org/2063693002 Cr-Commit-Position: refs/heads/master@{#37035}
-
- 13 Jun, 2016 2 commits
-
-
bmeurer authored
Import base::ieee754::atan() and base::ieee754::atan2() from fdlibm and introduce Float64Atan and Float64Atan2 TurboFan operators based on those, similar to what we already did for Float64Log and Float64Log1p. Rewrite Math.atan() and Math.atan2() as TurboFan builtin and use the operators to also inline Math.atan() and Math.atan2() into optimized TurboFan functions. R=yangguo@chromium.org BUG=v8:5086,v8:5095 Review-Url: https://codereview.chromium.org/2065503002 Cr-Commit-Position: refs/heads/master@{#36916}
-
bmeurer authored
Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p TurboFan operator based on that, similar to what we do for Float64Log. Rewrite Math.log1p() as TurboFan builtin and use that operator to also inline Math.log1p() into optimized TurboFan functions. Also unify the handling of the special IEEE 754 functions somewhat in the TurboFan backends. At some point we can hopefully express this completely in the InstructionSelector (once we have an idea what to do with the ST(0) return issue on IA-32/X87). Drive-by-fix: Add some more test coverage for the log function. R=yangguo@chromium.org BUG=v8:5086,v8:5092 Review-Url: https://codereview.chromium.org/2060743002 Cr-Commit-Position: refs/heads/master@{#36914}
-
- 10 Jun, 2016 1 commit
-
-
bmeurer authored
This switches Math.log to use an fdlibm based version of log, imported as base::ieee754::log, and use that consistently everywhere, i.e. change the Float64Log TurboFan operators on Intel to use the C++ implementation as well (same for Crankshaft). R=yangguo@chromium.org BUG=v8:5065,v8:5086 Review-Url: https://codereview.chromium.org/2053893003 Cr-Commit-Position: refs/heads/master@{#36880}
-
- 09 Jun, 2016 1 commit
-
-
danno authored
Review-Url: https://codereview.chromium.org/2056503003 Cr-Commit-Position: refs/heads/master@{#36842}
-
- 19 May, 2016 1 commit
-
-
danno authored
Review-Url: https://codereview.chromium.org/1995543003 Cr-Commit-Position: refs/heads/master@{#36355}
-
- 03 May, 2016 1 commit
-
-
binji authored
BUG=v8:4614 R=bmeurer@chromium.org,jarin@chromium.org LOG=n Review-Url: https://codereview.chromium.org/1938213002 Cr-Commit-Position: refs/heads/master@{#35993}
-
- 21 Apr, 2016 1 commit
-
-
baptiste.afsa authored
R=jarin@chromium.org Review URL: https://codereview.chromium.org/1897213003 Cr-Commit-Position: refs/heads/master@{#35709}
-
- 18 Apr, 2016 1 commit
-
-
binji authored
Reland of (https://codereview.chromium.org/1891033002) This is a much cleaner solution, which won't require nearly as much architecture-specific code. Thanks bmeurer@! BUG=v8:4614 LOG=y TBR=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1902433003 Cr-Commit-Position: refs/heads/master@{#35596}
-
- 16 Apr, 2016 2 commits
-
-
machenbach authored
Revert of [Atomics] Remove Atomics code stubs; use TF ops (patchset #6 id:100001 of https://codereview.chromium.org/1891033002/ ) Reason for revert: [Sheriff] Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20ASAN%20mipsel%20-%20debug%20builder/builds/6121 Original issue's description: > [Atomics] Remove Atomics code stubs; use TF ops > > This is a much cleaner solution, which won't require nearly as much > architecture-specific code. Thanks bmeurer@! > > BUG=v8:4614 > LOG=y > R=bmeurer@chromium.org,jarin@chromium.org > > Committed: https://crrev.com/6ff5881b1def45b35384572f61327e42563a89c3 > Cr-Commit-Position: refs/heads/master@{#35547} TBR=bmeurer@chromium.org,jarin@chromium.org,rodolph.perfetta@gmail.com,binji@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4614 Review URL: https://codereview.chromium.org/1895643002 Cr-Commit-Position: refs/heads/master@{#35548}
-
binji authored
This is a much cleaner solution, which won't require nearly as much architecture-specific code. Thanks bmeurer@! BUG=v8:4614 LOG=y R=bmeurer@chromium.org,jarin@chromium.org Review URL: https://codereview.chromium.org/1891033002 Cr-Commit-Position: refs/heads/master@{#35547}
-
- 14 Apr, 2016 1 commit
-
-
rmcilroy authored
Modifies Ignition to store code entry addresses in the dispatch table rather than code objects. This allows the interpreter to avoid calculating the code entry address from the code object on every dispatch and provides a ~5-7% performance improvement on Octane with Ignition. This change adds ArchOpcode::kArchTailCallAddress to TurboFan to enable tail call dispatch using these code addresses. It also adds a Dispatch linkage creator (distinct from the stub linkage type used previously) to allow targetting a code address target (which will diverge further from the stub linkage type when we remove the context machine register in Ignition). BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1882073002 Cr-Commit-Position: refs/heads/master@{#35480}
-
- 08 Mar, 2016 1 commit
-
-
ishell authored
In case when F tail calls G we should also remove the potential arguments adaptor frame for F. This CL introduces two new machine instructions ArchTailCallCodeObjectFromJSFunction and ArchTailCallJSFunctionFromJSFunction which (unlike existing ArchTailCallCodeObject and ArchTailCallJSFunction) also drop arguments adaptor frame if it exists right before jumping to the target function. BUG=v8:4698 LOG=N Review URL: https://codereview.chromium.org/1702423002 Cr-Commit-Position: refs/heads/master@{#34566}
-
- 29 Feb, 2016 1 commit
-
-
mtrofin authored
BUG= Review URL: https://codereview.chromium.org/1738973002 Cr-Commit-Position: refs/heads/master@{#34363}
-
- 19 Feb, 2016 2 commits
-
-
baptiste.afsa authored
Extract the logic to find out the best candidate out of the core of the scheduler. It allows more flexibility and make it easy to change the policy use to schedule the basic blocks. This patch also provide a new algorithm to randomly schedule the code in order to perform stress tests on the scheduler. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1714753004 Cr-Commit-Position: refs/heads/master@{#34156}
-
baptiste.afsa authored
ArchStackPointer operation should not be reordered with respect to instructions which can modify the stack layout. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1716543004 Cr-Commit-Position: refs/heads/master@{#34151}
-
- 16 Feb, 2016 2 commits
-
-
mstarzinger authored
The LazyBailout operator (modelled as a nop-call) was introduced for placing a deoptimization point into exception handlers. Now that we are no longer re-entering lazy deoptimized code, the support can be removed. R=jarin@chromium.org BUG=v8:4195 LOG=n Review URL: https://codereview.chromium.org/1697503002 Cr-Commit-Position: refs/heads/master@{#34020}
-
danno authored
This functionality is useful for stubs that need to walk the stack. The new machine operator, LoadParentFramePointer dosn't force the currently compiling method to have a frame in contrast to LoadFramePointer. Instead, it adapts accordingly when frame elision is possible, making efficient stack walks possible without incurring a performance penalty for small stubs that can benefit from frame elision. R=bmeurer@chromium.org LOG=N Review URL: https://codereview.chromium.org/1695313002 Cr-Commit-Position: refs/heads/master@{#34014}
-
- 29 Jan, 2016 3 commits
-
-
ahaas authored
The StackSlot operator allows to allocate a spill slot on the stack. We are going to use this operator to pass floats through pointers to c functions, which we need for floating point rounding in the case where the architecture does not provide rounding instructions. R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223 Cr-Commit-Position: refs/heads/master@{#33600} Review URL: https://codereview.chromium.org/1645653002 Cr-Commit-Position: refs/heads/master@{#33606}
-
ahaas authored
Revert of [turbofan] Add the StackSlot operator to turbofan. (patchset #4 id:60001 of https://codereview.chromium.org/1645653002/ ) Reason for revert: problems on Mac64 Original issue's description: > [turbofan] Add the StackSlot operator to turbofan. > > The StackSlot operator allows to allocate a spill slot on the stack. We > are going to use this operator to pass floats through pointers to c > functions, which we need for floating point rounding in the case where > the architecture does not provide rounding instructions. > > R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com > > Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223 > Cr-Commit-Position: refs/heads/master@{#33600} TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1644283002 Cr-Commit-Position: refs/heads/master@{#33601}
-
ahaas authored
The StackSlot operator allows to allocate a spill slot on the stack. We are going to use this operator to pass floats through pointers to c functions, which we need for floating point rounding in the case where the architecture does not provide rounding instructions. R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com Review URL: https://codereview.chromium.org/1645653002 Cr-Commit-Position: refs/heads/master@{#33600}
-
- 15 Dec, 2015 3 commits
-
-
baptiste.afsa authored
Original CL: https://codereview.chromium.org/1375253002/ Implement machine instruction scheduling after instruction selection. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1526913003 Cr-Commit-Position: refs/heads/master@{#32869}
-
yangguo authored
Revert of [WIP][turbofan] Instruction scheduler for Turbofan. (patchset #7 id:120001 of https://codereview.chromium.org/1375253002/ ) Reason for revert: Does not compile https://build.chromium.org/p/client.v8/builders/V8%20Arm%20-%20debug%20builder/builds/6870/steps/compile/logs/stdio Original issue's description: > [turbofan] Instruction scheduler for Turbofan. > > Implement machine instruction scheduling after instruction selection. > > Currently only works for arm64. > > R=danno@chromium.org, bmeurer@chromium.org, titzer@chromium.org > > Committed: https://crrev.com/e11bba3acd5188f0e12686b6fcf3e0ab22989216 > Cr-Commit-Position: refs/heads/master@{#32858} TBR=jarin@chromium.org,bmeurer@chromium.org,baptiste.afsa@arm.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1526913002 Cr-Commit-Position: refs/heads/master@{#32860}
-
baptiste.afsa authored
Implement machine instruction scheduling after instruction selection. Currently only works for arm64. R=danno@chromium.org, bmeurer@chromium.org, titzer@chromium.org Review URL: https://codereview.chromium.org/1375253002 Cr-Commit-Position: refs/heads/master@{#32858}
-