- 14 Jul, 2017 1 commit
-
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: Iecd5fc789b74ae8bcb4bdcb98fcf248c8bc6f6e7 Reviewed-on: https://chromium-review.googlesource.com/568478 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46668}
-
- 13 Jul, 2017 1 commit
-
-
Clemens Hammacher authored
There is just one version now, called IsPowerOfTwo. It accepts any integral type. There is one slight semantical change: Called with kMinInt, it previously returned true, because the argument was implicitly casted to an unsigned. It's now (correctly) returning false, so I had to add special handlings of kMinInt in machine-operator-reducer before calling IsPowerOfTwo on that value. R=mlippautz@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,ishell@chromium.org,yangguo@chromium.org Change-Id: Idc112a89034cdc8c03365b778b33b1c29fefb38d Reviewed-on: https://chromium-review.googlesource.com/568140Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46627}
-
- 23 Feb, 2017 1 commit
-
-
Marja Hölttä authored
BUG=v8:5294 Change-Id: If45f25aae8de526027b7851cb4efe0ccf4a7c4b1 Reviewed-on: https://chromium-review.googlesource.com/444226 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43388}
-
- 16 Feb, 2017 1 commit
-
-
Andreas Haas authored
One optimization in the machine-operator-reducer did not consider that that word32 shift left instructions only consider the last 5 bits of the shift input. The issue only occurs for WebAssembly because in JavaScript we always add a "& 0xf" on the shift value to the TurboFan graph. For additional background: The JavaScript and WebAssembly spec both say that only the last 5 bits of the shift value are used in the word32-shift-left operation. This means that an "x << 0x29", in the code is actually executed as "x << 0x09". Therefore the changes in this CL are okay because they mask the last 5 bit of the shift value. BUG=chromium:689450 Change-Id: Id92f298ed6d7f1714b109b3f4fbcecd5ac6d30f7 Reviewed-on: https://chromium-review.googlesource.com/439312Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43245}
-
- 03 Feb, 2017 1 commit
-
-
ahaas authored
R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2669753002 Cr-Commit-Position: refs/heads/master@{#42920}
-
- 02 Feb, 2017 1 commit
-
-
ahaas authored
R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2662363003 Cr-Commit-Position: refs/heads/master@{#42902}
-
- 01 Feb, 2017 1 commit
-
-
ahaas authored
I removed some constant folding optimizations for float instruction in https://codereview.chromium.org/2647353007 because they were incorrect if the input was a signalling NaN. Removing these optimizations, however had an unexpectedly big impact on asm.js performance. With this CL I restore the optimizations again when the source origin is not wasm. In JavaScript signalling NaNs are not observable and therefore the optimizations are correct. R=titzer@chromium.org BUG=chromium:686654 Review-Url: https://codereview.chromium.org/2666903002 Cr-Commit-Position: refs/heads/master@{#42850}
-
- 26 Jan, 2017 1 commit
-
-
ahaas authored
According to the WebAssembly spec no arithmetic operation should ever return a signalling NaN. With the constant folding in V8, however, it was possible that some arithmetic operations were elided, and if the input of the arithmetic operation was a signalling NaN, then also the result was the same signalling NaN. This CL removes some constant folding optimizations and adjusts others so that even with constant folding the result of an arithmetic operation is never a signalling NaN. R=titzer@chromium.org, rossberg@chromium.org, bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2647353007 Cr-Commit-Position: refs/heads/master@{#42694}
-
- 04 Jan, 2017 1 commit
-
-
bmeurer authored
R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2616613002 Cr-Commit-Position: refs/heads/master@{#42058}
-
- 30 Nov, 2016 1 commit
-
-
titzer authored
R=ahaas@chromium.org,bradnelson@chromium.org BUG= Review-Url: https://codereview.chromium.org/2528033002 Cr-Commit-Position: refs/heads/master@{#41381}
-
- 27 Sep, 2016 1 commit
-
-
epertoso authored
The MachineOperatorReducer was only reducing word32 expressions of the type x << y | x >>> (32 - y) (and variants) to the equivalent Word32Ror. This CL applies the same pattern-matching logic to Word32Xor. BUG= Committed: https://crrev.com/a86397d890d3caa01a947e2a6e71beb1f58e6e6b Review-Url: https://codereview.chromium.org/2199323003 Cr-Original-Commit-Position: refs/heads/master@{#38284} Cr-Commit-Position: refs/heads/master@{#39757}
-
- 16 Sep, 2016 1 commit
-
-
martyn.capewell authored
For denominators that are powers of two, replace Float64 division with multiplication by the reciprocal. Additionally, replace division by -1 with negation, and multiplication by two with addition. BUG= Review-Url: https://codereview.chromium.org/2347573002 Cr-Commit-Position: refs/heads/master@{#39478}
-
- 13 Sep, 2016 1 commit
-
-
bmeurer authored
Also unify the Pow implementation somewhat. There are still some inconsistencies with the FPU version for x64/ia32, but that has to be resolved separately. R=ahaas@chromium.org, mvstanton@chromium.org BUG=v8:5086 Review-Url: https://codereview.chromium.org/2333663002 Cr-Commit-Position: refs/heads/master@{#39368}
-
- 10 Aug, 2016 1 commit
-
-
epertoso authored
Revert of [turbofan] Reduces x << y ^ x >>> (32 - y) to x ror (32 - y). (patchset #1 id:1 of https://codereview.chromium.org/2199323003/ ) Reason for revert: It may or may not have caused a regression in kraken-crypto-ccm. Original issue's description: > [turbofan] Reduces x << y ^ x >>> (32 - y) to x ror (32 - y). > > The MachineOperatorReducer was only reducing word32 expressions of the type x << y | x >>> (32 - y) (and variants) to the equivalent Word32Ror. This CL applies the same pattern-matching logic to Word32Xor. > > BUG= > > Committed: https://crrev.com/a86397d890d3caa01a947e2a6e71beb1f58e6e6b > Cr-Commit-Position: refs/heads/master@{#38284} TBR=bmeurer@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. NOPRESUBMIT=true BUG= Review-Url: https://codereview.chromium.org/2230213002 Cr-Commit-Position: refs/heads/master@{#38545}
-
- 08 Aug, 2016 1 commit
-
-
ahaas authored
Up until now "-0.0 - x" was lowered in the instruction selector. I moved the lowering now to the MachineOperatorReducer. I did not remove the lowering from the instruction selector yet, I would prefer to do that in a separate CL. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2226663002 Cr-Commit-Position: refs/heads/master@{#38417}
-
- 04 Aug, 2016 1 commit
-
-
epertoso authored
Only basic things for now, but enough, for example, to emit mov rax, [rax+0xc] instead of mov rax, 0x3 mov rdx, [rdx+rax*4] on x64. BUG= Review-Url: https://codereview.chromium.org/2211633003 Cr-Commit-Position: refs/heads/master@{#38338}
-
- 03 Aug, 2016 1 commit
-
-
epertoso authored
The MachineOperatorReducer was only reducing word32 expressions of the type x << y | x >>> (32 - y) (and variants) to the equivalent Word32Ror. This CL applies the same pattern-matching logic to Word32Xor. BUG= Review-Url: https://codereview.chromium.org/2199323003 Cr-Commit-Position: refs/heads/master@{#38284}
-
- 25 Jul, 2016 1 commit
-
-
mvstanton authored
After multiplying two integers we emit code like: if (result == 0) { if (OR_OPERATION(rhs, lhs) < 0) { DEOPT; } } This CL allows us to eliminate the OR and comparison if either rhs or lhs is a negative number, reducing the code to: if (result == 0) DEOPT; BUG= Review-Url: https://codereview.chromium.org/2167643002 Cr-Commit-Position: refs/heads/master@{#38016}
-
- 22 Jul, 2016 1 commit
-
-
ivica.bogosavljevic authored
Implement UnalignedLoad and UnalignedStore optional turbofan operators and use them in WasmCompiler for unaligned memory access. BUG= Review-Url: https://codereview.chromium.org/2122853002 Cr-Commit-Position: refs/heads/master@{#37988}
-
- 14 Jul, 2016 1 commit
-
-
bmeurer authored
Add simple strength reduction for Int32MulWithOverflow to the MachineOperatorReducer. R=mvstanton@chromium.org Review-Url: https://codereview.chromium.org/2139733003 Cr-Commit-Position: refs/heads/master@{#37751}
-
- 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}
-
- 22 Jun, 2016 1 commit
-
-
bmeurer authored
We cannot change x - y < 0 to x < y, because it would only be safe if x - y cannot overflow, which we don't know in general. R=jarin@chromium.org BUG=v8:5129 Review-Url: https://codereview.chromium.org/2090493002 Cr-Commit-Position: refs/heads/master@{#37164}
-
- 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 4 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}
-
martyn.capewell authored
If (mask >>> s) == 0, ((x & mask) >> s) == 0, so replace the node with zero in MachineOperatorReducer. BUG= Review-Url: https://codereview.chromium.org/2069973002 Cr-Commit-Position: refs/heads/master@{#37046}
-
- 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}
-
- 03 Jun, 2016 1 commit
-
-
bmeurer authored
Introduce a dedicated Float64Log machine operator, that is either implemented by a direct C call or by platform specific code, i.e. using the FPU on x64 and ia32. This operator is used to implement Math.log as a proper TurboFan builtin on top of the CodeStubAssembler. Also introduce a NumberLog simplified operator on top of Float64Log and use that for the fast inline path of Math.log inside TurboFan optimized code. BUG=v8:5065 Review-Url: https://codereview.chromium.org/2029413005 Cr-Commit-Position: refs/heads/master@{#36703}
-
- 26 Apr, 2016 1 commit
-
-
martyn.capewell authored
Apply the mask elision code for Store to CheckedStore in the machine operator reducer. This is the arch independent part of https://codereview.chromium.org/1883133002 BUG= Review URL: https://codereview.chromium.org/1921673003 Cr-Commit-Position: refs/heads/master@{#35788}
-
- 24 Apr, 2016 1 commit
-
-
bmeurer authored
This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi" trick that was used in the MachineOperatorReducer to combine the ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of doing that later, we can just introduce the proper operator during the representation selection directly. Also separate the TruncateFloat64ToInt32 machine operator, which had two different meanings depending on a flag (either JavaScript truncation or C++ style round to zero). Now there's a TruncateFloat64ToWord32 which represents the JavaScript truncation (implemented via TruncateDoubleToI macro + code stub) and the RoundFloat64ToInt32, which implements the C++ round towards zero operation (in the same style as the other WebAssembly driven Round* machine operators). R=jarin@chromium.org Review URL: https://codereview.chromium.org/1919513002 Cr-Commit-Position: refs/heads/master@{#35743}
-
- 11 Jan, 2016 1 commit
-
-
titzer authored
R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1578723002 Cr-Commit-Position: refs/heads/master@{#33202}
-
- 11 Dec, 2015 1 commit
-
-
jarin authored
Review URL: https://codereview.chromium.org/1513383003 Cr-Commit-Position: refs/heads/master@{#32803}
-