Skip to content

V
V8
Switch branch/tag
  1. 06 May, 2016 2 commits
  3. 04 May, 2016 3 commits
    • pierre.langlois's avatar
      ARM64: [turbofan] Avoid zero-extension after a 32-bit load · f07d2cdd
      pierre.langlois authored 
      A load instruction will implicitely clear the top 32 bits when writing to a W
register. This patch avoids generating a `mov` instruction to zero-extend the
result in this case.

For example, this occurs in the generated code for dispatching to the next
bytecode in the interpreter:

  kind = BYTECODE_HANDLER
  name = LdaZero
  compiler = turbofan
  Instructions (size = 36)
  0x32e64c60     0  add x19, x19, #0x1 (1)
  0x32e64c64     4  ldrb w0, [x20, x19]
  0x32e64c68     8  mov w0, w0
                    ^^^^^^^^^^
  0x32e64c6c    12  lsl x0, x0, #3
  0x32e64c70    16  ldr x1, [x21, x0]
  0x32e64c74    20  movz x0, #0x0
  0x32e64c78    24  br x1

BUG=

Review-Url: https://codereview.chromium.org/1950013003
Cr-Commit-Position: refs/heads/master@{#36038}
      f07d2cdd
    • bmeurer's avatar
      [turbofan] Inline the allocation fast path. · ce38a8a9
      bmeurer authored 
      Now that everything is properly wired to the effect chain when we get to
ChangeLowering, we can safely inline the allocation fast path and only
need to consule the slow path stub fallback when bump pointer allocation
fails.

R=jarin@chromium.org
BUG=v8:4931
LOG=n

Review-Url: https://codereview.chromium.org/1951853002
Cr-Commit-Position: refs/heads/master@{#36022}
      ce38a8a9
    • martyn.capewell's avatar
      [turbofan] ARM64: Use zr to store immediate zero · 0322c20d
      martyn.capewell authored 
      When storing an immediate integer or floating point zero, use the zero register
as the source value. This avoids the need to sometimes allocate a new register.

BUG=

Review-Url: https://codereview.chromium.org/1945783002
Cr-Commit-Position: refs/heads/master@{#36013}
      0322c20d
  5. 03 May, 2016 1 commit
  7. 02 May, 2016 3 commits
    • bmeurer's avatar
      [turbofan] Remove left-over change bits from ChangeLowering. · 4aa02441
      bmeurer authored 
      Now ChangeLowering is only concerned with lowering memory access and
allocation operations, and all changes are consistently lowered during
the effect/control linearization pass. The next step is to move the
left over lowerings to a pass dedicated to eliminate redundant loads and
stores, eliminate write barriers, fold and inline allocations.

Drive-by-fix: Rename ChangeBitToBool to ChangeBitToTagged,
ChangeBoolToBit to ChangeTaggedToBit, and ChangeInt31ToTagged to
ChangeInt31ToTaggedSigned for consistency.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel

Committed: https://crrev.com/ceca5ae308bddda166651c654f96d71d74f617d0
Cr-Commit-Position: refs/heads/master@{#35924}

Review-Url: https://codereview.chromium.org/1941673002
Cr-Commit-Position: refs/heads/master@{#35929}
      4aa02441
    • machenbach's avatar
      Revert of [turbofan] Remove left-over change bits from ChangeLowering.... · b4c3864b
      machenbach authored 
      Revert of [turbofan] Remove left-over change bits from ChangeLowering. (patchset #2 id:20001 of https://codereview.chromium.org/1941673002/ )

Reason for revert:
[Sheriff] Breaks mac gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/5821

Original issue's description:
> [turbofan] Remove left-over change bits from ChangeLowering.
>
> Now ChangeLowering is only concerned with lowering memory access and
> allocation operations, and all changes are consistently lowered during
> the effect/control linearization pass. The next step is to move the
> left over lowerings to a pass dedicated to eliminate redundant loads and
> stores, eliminate write barriers, fold and inline allocations.
>
> Also remove the atomic regions now that we wire everything into the
> effect chain properly. This is an important step towards allocation
> inlining.
>
> Drive-by-fix: Rename ChangeBitToBool to ChangeBitToTagged,
> ChangeBoolToBit to ChangeTaggedToBit, and ChangeInt31ToTagged to
> ChangeInt31ToTaggedSigned for consistency.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
>
> Committed: https://crrev.com/ceca5ae308bddda166651c654f96d71d74f617d0
> Cr-Commit-Position: refs/heads/master@{#35924}

TBR=ishell@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/1942733002
Cr-Commit-Position: refs/heads/master@{#35927}
      b4c3864b
    • bmeurer's avatar
      [turbofan] Remove left-over change bits from ChangeLowering. · ceca5ae3
      bmeurer authored 
      Now ChangeLowering is only concerned with lowering memory access and
allocation operations, and all changes are consistently lowered during
the effect/control linearization pass. The next step is to move the
left over lowerings to a pass dedicated to eliminate redundant loads and
stores, eliminate write barriers, fold and inline allocations.

Also remove the atomic regions now that we wire everything into the
effect chain properly. This is an important step towards allocation
inlining.

Drive-by-fix: Rename ChangeBitToBool to ChangeBitToTagged,
ChangeBoolToBit to ChangeTaggedToBit, and ChangeInt31ToTagged to
ChangeInt31ToTaggedSigned for consistency.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel

Review-Url: https://codereview.chromium.org/1941673002
Cr-Commit-Position: refs/heads/master@{#35924}
      ceca5ae3
  9. 25 Apr, 2016 4 commits
  11. 24 Apr, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce TruncateTaggedToWord32 simplified operator. · 0231a7ef
      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}
      0231a7ef
  13. 22 Apr, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Move more type checks to the representation selector. · 550c0f9f
      bmeurer authored 
      Get rid of further typing checks from ChangeLowering and put them into
the representation selection pass instead (encoding the information in
the operator instead).

Drive-by-change: Rename ChangeSmiToInt32 to ChangeTaggedSignedToInt32
for consistency about naming Tagged, TaggedSigned and TaggedPointer.

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/1909343002

Cr-Commit-Position: refs/heads/master@{#35723}
      550c0f9f
    • bmeurer's avatar
      [turbofan] Optimize tagged conversion based on type. · 861295bf
      bmeurer authored 
      If we have to convert a float64 value to tagged representation and we
already know that the value is either in Signed31/Signed32 or
Unsigned32 range, then we can just convert the float64 to word32 and
use the fast word32 to tagged conversion. Doing this in
ChangeLowering (or the effect linearization pass) would be unsound, as
the types on the nodes are no longer usable.

This removes all Type uses from effect linearization. There's still some
work to be done for ChangeLowering tho.

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/1908093002

Cr-Commit-Position: refs/heads/master@{#35713}
      861295bf
  15. 19 Apr, 2016 1 commit
  17. 18 Apr, 2016 1 commit
    • jarin's avatar
      [turbofan] Effect linearization after representation inference. · b9e287c6
      jarin authored 
      This introduces a compiler pass that schedules the graph and re-wires effect chain according to the schedule. It also connects allocating representation changes to the effect chain, and removes the BeginRegion and EndRegion nodes - they should not be needed anymore because all effectful nodes should be already wired-in.

This is an intermediate CL - the next step is to move lowering of the Change*ToTaggedEffect nodes to StateEffectIntroduction so that we do not have to introduce the effectful versions of nodes.

Review URL: https://codereview.chromium.org/1849603002

Cr-Commit-Position: refs/heads/master@{#35565}
      b9e287c6
  19. 16 Apr, 2016 1 commit
  21. 14 Apr, 2016 3 commits
  23. 08 Apr, 2016 1 commit
  25. 06 Apr, 2016 1 commit
  27. 05 Apr, 2016 1 commit
    • jarin's avatar
      [turbofan] Restrict types in load elimination. · 4142bc6b
      jarin authored 
      In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.

In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).

BUG=chromium:599412
LOG=n

Review URL: https://codereview.chromium.org/1857133003

Cr-Commit-Position: refs/heads/master@{#35259}
      4142bc6b
  29. 04 Apr, 2016 1 commit
    • titzer's avatar
      [turbofan] Handle dead diamonds in scheduling and add a test. · 45d75bca
      titzer authored 
      The background here is that graphs generated from WASM are not trimmed.
That means there can be some floating control diamonds that are not
reachable from end. An assertion in the scheduler for phis from floating
diamonds checks that the use edge in this situation is the control edge,
but in general, any edge could cause this.

Scheduling still works without this assertion. The longer term fix
is to either trim the graphs (more compile time overhead for WASM)
or improve the scheduler's handling of dead code in the graph. Currently
it does not schedule dead code but the potential use positions of
dead code are used in the computation of the common dominator of uses. We could
recognize dead nodes in PrepareUses() and check in GetBlockForUse()
as per TODO.

R=bradnelson@chromium.org, mstarzinger@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1846933002

Cr-Commit-Position: refs/heads/master@{#35245}
      45d75bca
  31. 01 Apr, 2016 2 commits
  33. 31 Mar, 2016 1 commit
  35. 30 Mar, 2016 2 commits
    • ahaas's avatar
      [wasm] Int64Lowering of Int64Mul on ia32 and arm. · 40bdbef9
      ahaas authored 
      Int64Mul is lowered to a new turbofan operator, Int32MulPair. The new
operator takes 4 inputs an generates 2 outputs. The inputs are the low
word of the left input, high word of the left input, the low word of the
right input, and high word of the right input. The ouputs are the low
and high word of the result of the multiplication.

R=titzer@chromium.org, v8-arm-ports@googlegroups.com

Review URL: https://codereview.chromium.org/1807273002

Cr-Commit-Position: refs/heads/master@{#35131}
      40bdbef9
    • ahaas's avatar
      [wasm] New attempt to implement the Int64Lowering of phis. · 682df6dd
      ahaas authored 
      The new implementation deals with cycles in the TF graph in two steps:
1) The lowering of phis is delayed to avoid cyclic dependencies.
2) The replacement nodes of phis are created already when the phi is
   pushed onto the stack so that other nodes can use these replacements
   for their lowering.

R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1844553002

Cr-Commit-Position: refs/heads/master@{#35126}
      682df6dd
  37. 28 Mar, 2016 1 commit
    • bmeurer's avatar
      [builtins] Provide Math.floor as TurboFan builtin. · 36ead519
      bmeurer authored 
      This way we avoid the second deoptimization for the Math.floor and
Math.ceil builtins when -0 is involved. We still deoptimize the inlined
Crankshaft version in various cases, that's a separate issue.

The algorithm used for implement CodeStubAssembler::Float64Floor is
vaguely based on the fast math version used in the libm of various BSDs,
but had to be reengineered to match the EcmaScript specification.

R=epertoso@chromium.org
BUG=v8:2890, v8:4059
LOG=n

Review URL: https://codereview.chromium.org/1828253002

Cr-Commit-Position: refs/heads/master@{#35083}
      36ead519
  39. 22 Mar, 2016 2 commits
  41. 17 Mar, 2016 1 commit
  43. 16 Mar, 2016 3 commits
  45. 15 Mar, 2016 2 commits