Skip to content

V
V8
Switch branch/tag
  1. 26 Jul, 2016 1 commit
  3. 25 Jul, 2016 1 commit
  5. 22 Jul, 2016 2 commits
    • ivica.bogosavljevic's avatar
      Implement UnaligedLoad and UnaligedStore turbofan operators. · 580fdf3c
      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}
      580fdf3c
    • bmeurer's avatar
      [turbofan] Change Float64Max/Float64Min to JavaScript semantics. · ba092fb0
      bmeurer authored 
      So far we don't have a useful way to inline Math.max or Math.min in
TurboFan optimized code. This adds new operators NumberMax and NumberMin
and changes the Float64Max/Float64Min operators to have JavaScript
semantics instead of the C++ semantics that it had previously.

This also removes support for recognizing the tenary case in the
CommonOperatorReducer, since that doesn't seem to have any positive
impact (and actually doesn't show up in regular JavaScript, where
people use Math.max/Math.min instead).

Drive-by-fix: Also nuke the unused Float32Max/Float32Min operators.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2170343002
Cr-Commit-Position: refs/heads/master@{#37971}
      ba092fb0
  7. 18 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add support for eager/soft deoptimization reasons. · db635d5b
      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}
      db635d5b
  9. 15 Jul, 2016 1 commit
    • ssanfilippo's avatar
      Emit unwinding information for TurboFan code. · cecded1c
      ssanfilippo authored 
      This commit introduces support for writing unwinding tables in the
.eh_frame format, to be inserted in the jitdump read by Linux perf and
emitted with FLAG_perf_prof and FLAG_perf_prof_unwinding_info enabled.

x64 is fully implemented and tested, arm and arm64 are untested and the
unwinding information needs to be expanded, but the mechanism is ready.

BUG=v8:4899
LOG=N

Review-Url: https://codereview.chromium.org/2026313002
Cr-Commit-Position: refs/heads/master@{#37799}
      cecded1c
  11. 14 Jul, 2016 1 commit
  13. 13 Jul, 2016 2 commits
  15. 12 Jul, 2016 1 commit
  17. 11 Jul, 2016 3 commits
  19. 01 Jul, 2016 2 commits
    • danno's avatar
      [turbofan]: Support using push instructions for setting up tail call parameters · bd0d9e7d
      danno authored 
      This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.

Review-Url: https://codereview.chromium.org/2082263002
Cr-Commit-Position: refs/heads/master@{#37477}
      bd0d9e7d
    • bmeurer's avatar
      [builtins] Unify most of the remaining Math builtins. · 0a0fe8fb
      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}
      0a0fe8fb
  21. 30 Jun, 2016 1 commit
  23. 28 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce Float64Pow and NumberPow operators. · e607e12e
      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}
      e607e12e
  25. 20 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Tan operator. · c87168bc
      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}
      c87168bc
  27. 17 Jun, 2016 3 commits
  29. 16 Jun, 2016 3 commits
  31. 15 Jun, 2016 1 commit
  33. 14 Jun, 2016 2 commits
  35. 13 Jun, 2016 2 commits
    • bmeurer's avatar
      [builtins] Introduce proper Float64Atan and Float64Atan2 operators. · 89d8c57b
      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}
      89d8c57b
    • bmeurer's avatar
      [builtins] Introduce proper Float64Log1p operator. · 7ceed92a
      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}
      7ceed92a
  37. 10 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper base::ieee754::log. · d0c7775d
      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}
      d0c7775d
  39. 09 Jun, 2016 1 commit
  41. 03 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Math.log to TurboFan. · f2da19fe
      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}
      f2da19fe
  43. 01 Jun, 2016 1 commit
  45. 27 May, 2016 2 commits
  47. 24 May, 2016 1 commit
    • epertoso's avatar
      [x64/ia32] Deal with the non-transitivity of InstructionSelector::CanCover()... · 0d22e7e4
      epertoso authored 
      [x64/ia32] Deal with the non-transitivity of InstructionSelector::CanCover() when folding loads into branches.

Sequences like:

1: Load[kRepWord32|kTypeInt32](<address>, ...)
2: Word32And(1, <constant>)
3: Word32Equal(2, <another constant>)
4: Store[(kRepWord32 : NoWriteBarrier)](<address>, <value>)
5: Branch[None](3, ...) -> B1, B2

where #1 and #4 refer to the same memory location, are problematic because in VisitBranch we assume that 'InstructionSelector::CanCover()' is transitive.

What happens is that CanCover(5, 3) is true (3 is a pure op), and so are CanCover(3, 2), CanCover(2, 1), but the effect level of 5 and 3 never gets checked because 3 is a pure op. Upon VisitBranch, we ended up materializing:

mov [address], <value>
test [address], <another constant>

With this patch, it becomes:

mov reg, [address]
mov [address], <value>
test reg, <another constant>

BUG=chromium:611976

Review-Url: https://codereview.chromium.org/2008493002
Cr-Commit-Position: refs/heads/master@{#36482}
      0d22e7e4
  49. 20 May, 2016 2 commits
  51. 19 May, 2016 1 commit
  53. 12 May, 2016 1 commit