1. 17 Jan, 2020 2 commits
  2. 16 Jan, 2020 5 commits
  3. 15 Jan, 2020 6 commits
  4. 14 Jan, 2020 5 commits
  5. 13 Jan, 2020 4 commits
  6. 10 Jan, 2020 4 commits
    • Milad Farazmand's avatar
      s390: [wasm-simd] Implementing simd comparisons · 17298faa
      Milad Farazmand authored
      Change-Id: I60e839b0272a7dc13852549f543c9fa724f7fd36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1994821Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#65712}
      17298faa
    • Thibaud Michaud's avatar
      [regalloc] Remove unnecessary ForwardStateTo · 8b5596ba
      Thibaud Michaud authored
      This call to {ForwardStateTo} seems unnecessary, as suggested by the
      comment.
      
      R=sigurds@chromium.org
      
      Bug: v8:10021
      Change-Id: I2ec3b54eda0cf5c53c2b5d3ad481a4581e024320
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993979Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65708}
      8b5596ba
    • Nico Hartmann's avatar
      Removes premature constant folding in CodeAssembler · f2503fee
      Nico Hartmann authored
      Many binary operations defiend in CodeAssembler check for constants
      in the inputs and apply simplification if applicable. This is now
      performed by the MachineOperatorReducer in a uniform way. To avoid
      code duplication, the premature optimizations in CodeAssembler have
      been removed in this CL.
      
      Bug: v8:10021
      Change-Id: I9b99f05e4f9ab31ff933f22d62674ee80efee8ac
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995277Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65707}
      f2503fee
    • Seth Brenith's avatar
      [torque] move more bitfield definitions to Torque · 87c16da5
      Seth Brenith authored
      This change moves the definitions of the bitfield flags used by Symbol
      and Map to Torque. Symbol could directly follow the pattern established
      by SharedFunctionInfo, but Map required some other changes:
      - Until now, Torque bitfield definitions have required unsigned types. I
        thought that this would be the least-surprising behavior, since we
        never sign-extend when decoding bitfield values. However, I believe
        that the amount of churn involved in making ElementsKind be unsigned
        outweighs the benefit we were getting from this restriction (and
        similar difficulties are likely to arise in converting other bitfield
        structs to Torque), so this CL updates Torque to allow signed bitfield
        values.
      - If we try to make Map extend from all of the generated classes that
        define its flags, we end up with class sizing problems because some
        compilers only apply empty base class optimization to the first in a
        row of empty base classes. We could work around this issue by
        generating macros instead of classes, but I took this as an
        opportunity for a minor clean-up instead: rather than having bitfield
        definitions for several different bitfield structs all jumbled
        together in Map, they can be split up. I think this makes the code a
        little easier to follow, but if others disagree I'm happy to implement
        macro generation instead.
      
      Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65701}
      87c16da5
  7. 09 Jan, 2020 5 commits
  8. 08 Jan, 2020 8 commits
  9. 07 Jan, 2020 1 commit