1. 03 May, 2016 16 commits
  2. 02 May, 2016 10 commits
    • jyan's avatar
      S390: Fix storing to below stack to avoid sampler handler corrupting stored value · 141bc11e
      jyan authored
      R=joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      
      Review-Url: https://codereview.chromium.org/1936953004
      Cr-Commit-Position: refs/heads/master@{#35953}
      141bc11e
    • jyan's avatar
      S390X: Prevent upper 32bit corruption in 32bit ops · 59b9ff3f
      jyan authored
      Fix A couple places which could cause upper 32bit corruption
      
      R=joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      
      Review-Url: https://codereview.chromium.org/1939763003
      Cr-Commit-Position: refs/heads/master@{#35952}
      59b9ff3f
    • bbudge's avatar
      Turbofan: Add MachineOperators for SIMD. · 1c94bed6
      bbudge authored
      Takes the SIMD runtime intrinsics as a starting point for defining TF machine operators. The rationale for omitting functions is:
      
       - Check functions.
       - 'FromXxxBits' functions. These are essentially casts.
       - UInt constructors. int and uint aren't distinguished in wasm.
       - Uint functions, except where their behavior is bitwise different from the Int function.
      
      Some operators are typeless, i.e. they are the same for multiple related types, e.g. logical ops for int types, load/store for float and int types. Use a 'Simd128' prefix for these operators.
      
      Skipped fns:
      
      Float32x4Check
      Float32x4FromInt32x4Bits
      Float32x4FromUint32x4Bits
      Float32x4FromInt16x8Bits
      Float32x4FromUint16x8Bits
      Float32x4FromInt8x16Bits
      Float32x4FromUint8x16Bits
      
      Int32x4Check
      Int32x4FromUint32x4
      Int32x4FromFloat32x4Bits
      Int32x4FromUint32x4Bits
      Int32x4FromInt16x8Bits
      Int32x4FromUint16x8Bits
      Int32x4FromInt8x16Bits
      Int32x4FromUint8x16Bits
      
      CreateUint32x4
      Uint32x4Check
      Uint32x4ExtractLane
      Uint32x4ReplaceLane
      Uint32x4Add
      Uint32x4Sub
      Uint32x4Mul
      Uint32x4And
      Uint32x4Or
      Uint32x4Xor
      Uint32x4Not
      Uint32x4Equal
      Uint32x4NotEqual
      Uint32x4Select
      Uint32x4Swizzle
      Uint32x4Shuffle
      Uint32x4FromInt32x4
      Uint32x4FromFloat32x4Bits
      Uint32x4FromInt32x4Bits
      Uint32x4FromInt16x8Bits
      Uint32x4FromUint16x8Bits
      Uint32x4FromInt8x16Bits
      Uint32x4FromUint8x16Bits
      
      Bool32x4Check
      
      Int16x8Check
      Int16x8FromUint16x8
      Int16x8FromFloat32x4Bits
      Int16x8FromInt32x4Bits
      Int16x8FromUint32x4Bits
      Int16x8FromUint16x8Bits
      Int16x8FromInt8x16Bits
      Int16x8FromUint8x16Bits
      
      CreateUint16x8
      Uint16x8Check
      Uint16x8ExtractLane
      Uint16x8ReplaceLane
      Uint16x8Add
      Uint16x8Sub
      Uint16x8Mul
      Uint16x8And
      Uint16x8Or
      Uint16x8Xor
      Uint16x8Not
      Uint16x8Equal
      Uint16x8NotEqual
      Uint16x8Select
      Uint16x8Swizzle
      Uint16x8Shuffle
      Uint16x8FromInt16x8
      Uint16x8FromFloat32x4Bits
      Uint16x8FromInt32x4Bits
      Uint16x8FromUint32x4Bits
      Uint16x8FromInt16x8Bits
      Uint16x8FromInt8x16Bits
      Uint16x8FromUint8x16Bits
      
      Bool16x8Check
      
      Int8x16Check
      Int8x16FromUint8x16
      Int8x16FromFloat32x4Bits
      Int8x16FromInt32x4Bits
      Int8x16FromUint32x4Bits
      Int8x16FromInt16x8Bits
      Int8x16FromUint16x8Bits
      Int8x16FromUint8x16Bits
      
      CreateUint8x16
      Uint8x16Check
      Uint8x16ExtractLane
      Uint8x16ReplaceLane
      Uint8x16Add
      Uint8x16Sub
      Uint8x16Mul
      Uint8x16And
      Uint8x16Or
      Uint8x16Xor
      Uint8x16Not
      Uint8x16Equal
      Uint8x16NotEqual
      Uint8x16Select
      Uint8x16Swizzle
      Uint8x16Shuffle
      Uint8x16FromInt8x16
      Uint8x16FromFloat32x4Bits
      Uint8x16FromInt32x4Bits
      Uint8x16FromUint32x4Bits
      Uint8x16FromInt16x8Bits
      Uint8x16FromUint16x8Bits
      Uint8x16FromInt8x16Bits
      
      Bool8x16Check
      
      Generic operators for Float, Int types:
      
      Simd128Load
      Simd128Load1
      Simd128Load2
      Simd128Load3
      Simd128Store
      Simd128Store1
      Simd128Store2
      Simd128Store3
      
      Generic operators for Int types:
      
      Simd128And
      Simd128Or
      Simd128Xor
      Simd128Not
      
      LOG=N
      BUG=v8:4124
      
      Committed: https://crrev.com/3831d41e4ce7b162775732cb6ac1f8139e60aa30
      Cr-Commit-Position: refs/heads/master@{#35213}
      
      Review-Url: https://codereview.chromium.org/1848433003
      Cr-Commit-Position: refs/heads/master@{#35951}
      1c94bed6
    • mstarzinger's avatar
      [compiler] Untangle CompilationInfo allocated with new. · 601ee4eb
      mstarzinger authored
      This removes the CompilationInfoWithZone class, which was used to
      allocate a CompilationInfo on the C-heap. By now the CompilationJob is
      the single object being allocated on the C-heap and passed between the
      main thread and the compilation thread. Structs requiring destruction
      can be embedded within that CompilationJob. This simplifies involved
      lifetimes by coupling all lifetimes to one single object.
      
      R=bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/1930773003
      Cr-Commit-Position: refs/heads/master@{#35936}
      601ee4eb
    • bmeurer's avatar
      [turbofan] Extend the type fixup to LoadField as well. · c0e65ea8
      bmeurer authored
      For LoadElimination we must not replace LoadField nodes with other nodes
      whose types are not a subtype of the original LoadField type, as that
      breaks the verifier. We already fixed that earlier for store to load
      forwarding, but the fix didn't cover LoadField forwarding.
      
      This actually still generates the correct code even w/o the fix, but
      since recently fails due to stronger checking in representation
      selection. So this makes clusterfuzz happy again.
      
      R=mvstanton@chromium.org
      BUG=chromium:607899
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1934973002
      Cr-Commit-Position: refs/heads/master@{#35930}
      c0e65ea8
    • 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
    • clemensh's avatar
      [wasm] Pass byte position for trapping instructions · bf1797b1
      clemensh authored
      During ast decoding and turbofan graph construction, we explicitely pass
      the byte offset for all instructions which potentially trap.
      The byte offset is finally passed to the runtime function which throws
      the actual error, but it is not used there yet.
      
      The WasmGraphBuilder::Binop and Unop methods have a default value of -1
      for the position, which allows for more compact code for all the
      functions which assemble bigger snippets from the primitive operations.
      Whenever the position is actually used for generating a trap, we
      check that it is not negative.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/1915123006
      Cr-Commit-Position: refs/heads/master@{#35925}
      bf1797b1
    • 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
    • bmeurer's avatar
      [turbofan] Nuke types before entering the concurrent phase. · 914ad0a3
      bmeurer authored
      It is unsound to look at the types in the TurboFan graphs after the
      representation selection (and early optimization) phases, because
      
       (a) the remaining phases (might) run concurrently, and
       (b) the types may not be accurate (or even correct) after
           representation selection due to the way we deal with
           truncations.
      
      So in Debug builds we now explicitly remove all types from the nodes
      right after we uninstall the Typer decorator from the Graph, so any
      further attempt to access the Type of a Node will lead to a crash (again
      in Debug only for now).
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
      BUG=v8:4969
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1937803002
      Cr-Commit-Position: refs/heads/master@{#35920}
      914ad0a3
  3. 30 Apr, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Run everything after representation selection concurrently. · d1b3d426
      bmeurer authored
      Further refactor the pipeline to even run the first scheduler (part of
      the effect control linearization) concurrently. This temporarily
      disables most of the write barrier elimination, but we will get back to
      that later.
      
      Drive-by-fix: Remove the dead code from ChangeLowering, and stack
      allocate the Typer in the pipeline. Also migrate the AllocateStub to a
      native code builtin, so that we have the code object + a handle to it
      available all the time.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
      R=mstarzinger@chromium.org
      BUG=v8:4969
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1926023002
      Cr-Commit-Position: refs/heads/master@{#35918}
      d1b3d426
  4. 29 Apr, 2016 5 commits
  5. 28 Apr, 2016 6 commits
  6. 27 Apr, 2016 2 commits