1. 17 Sep, 2018 3 commits
    • Benedikt Meurer's avatar
      [cleanup] Cleanup JSArrayBuffer and TurboFan's handling of neutering. · beebb236
      Benedikt Meurer authored
      Cleanup the JSArrayBuffer bit fields to use the proper object macros
      that are now otherwise used consistently across the code base. Also
      change TurboFan to consistently bailout when it sees an array buffer
      that was previously neutered, so that the generic path / builtins are
      again the chokepoints for the spec violations (the fact that we don't
      always raise exceptions when we see a neutered array buffer), except
      for the ArrayBufferView accessor inlining in the JSCallReducer, where
      we still turn the values into zero (because we don't have access to
      a CALL_IC speculation guard in the common case).
      
      This also removes the ArrayBufferWasNeutered simplified operator, and
      does regular LoadField + Number bitwise operations instead, which is
      good enough and allows us to get rid of a lot of unnecessary complexity.
      
      Bug: v8:4153, v8:7881, v8:8015, v8:8171, v8:8178
      Change-Id: I4ce79ece762c632e6318f2ab7bcc6b2f82383947
      Reviewed-on: https://chromium-review.googlesource.com/1226887Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55958}
      beebb236
    • Benedikt Meurer's avatar
      [turbofan] Change FindOrderedHashEntryForInt32Key to return Word64 (on 64-bit). · 796292a9
      Benedikt Meurer authored
      The computation to find the hash entry is already performed on Word64,
      and the actual value access later is also performed on Word64 indices,
      so there's no point to go to Word32 in between.
      
      Bug: v8:8015, v8:8178
      Change-Id: I160e02166beceb79dcc8e69f9c365871a4c42606
      Reviewed-on: https://chromium-review.googlesource.com/1226648Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55950}
      796292a9
    • Benedikt Meurer's avatar
      [turbofan] Initial support to compute NumberAdd/NumberSubtract in Word64. · 0c296cb2
      Benedikt Meurer authored
      This change introduces the necessary conversion operators to convert
      from Word64 to other representations (Tagged, Word32, Float64, etc.),
      and plugs in the Word64 representation for NumberAdd/NumberSubtract,
      such that TurboFan will go to Int64Add/Sub on 64-bit architectures
      when the inputs and the output of the operation is in safe integer
      range. This includes the necessary changes to the Deoptimizer to be
      able to rematerialize Int64 values as Smi/HeapNumber when going back
      to Ignition later.
      
      This change might affect performance, although measurements indicate
      that there should be no noticable performance impact.
      
      The goal is to have TurboFan support Word64 representation to a degree
      that changing the TypedArray length to an uint64_t (for 64-bit archs)
      becomes viable and doesn't have any negative performance implications.
      Independent of that we might get performance improvements in other areas
      such as for crypto code later.
      
      Bug: v8:4153, v8:7881, v8:8171, v8:8178
      Design-Document: bit.ly/turbofan-word64
      Change-Id: I29d56e2a31c1bae61d04a89d29ea73f21fd49c59
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
      Reviewed-on: https://chromium-review.googlesource.com/1225709
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55937}
      0c296cb2
  2. 14 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Initial Word64 support in representation selection. · 6346cdb6
      Benedikt Meurer authored
      This adds support to TurboFan's representation selection for the Word64
      representation, and makes use of that to handle indices for memory access
      and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
      etc.). These instructions had previously used Word32 as representation
      for the indices / sizes, and then internally converted it to the correct
      representation (aka Word64 on 64-bit architectures) later on, but that
      was kind of brittle, and sometimes led to weird generated code.
      
      The change thus only adds support to convert integer values in the safe
      integer range from all kinds of representations to Word64 (on 64-bit
      architectures). We don't yet handle the opposite direction and none of
      the representation selection heuristics for the numeric operations were
      changed so far. This will be done in follow-up CLs.
      
      This CL itself is supposed to be neutral wrt. functionality, and only
      serves as a starting point, and a cleanup for the (weird) implicit
      Word64 index/size handling.
      
      Bug: v8:7881, v8:8015, v8:8171
      Design-Document: http://bit.ly/turbofan-word64
      Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
      Reviewed-on: https://chromium-review.googlesource.com/1224932
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55886}
      6346cdb6
  3. 13 Sep, 2018 2 commits
  4. 12 Sep, 2018 6 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "[objects] Change String::length field to uint32_t."" · 350dfb62
      Sathya Gunasekaran authored
      This reverts commit a03cec2c.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/21320
      
      Original change's description:
      > Reland "[objects] Change String::length field to uint32_t."
      > 
      > This is a reland of 1f1eb625, the
      > breakage on the GCStress bot seems to be unrelated (maybe flushed
      > out by this change). We decided to reland to figure out whether it's
      > a random flake or really triggered by this particular change.
      > 
      > Original change's description:
      > > [objects] Change String::length field to uint32_t.
      > >
      > > This changes the Name::hash_field and Symbol::flags to uint32_t as
      > > well, so that both Symbols and Strings consume one fewer word on 64-bit
      > > architectures now. More importantly the access to String::length is
      > > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      > > on 64-bit with pointer compression), so the access should be faster.
      > >
      > > Bug: v8:7065, v8:8171
      > > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      > > Reviewed-on: https://chromium-review.googlesource.com/1221288
      > > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#55825}
      > 
      > Bug: v8:7065, v8:8171
      > Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org, ulan@chromium.org
      > Change-Id: I2be24ac018591c04c826e7e8db82e007b738d156
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/1222308
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55838}
      
      TBR=yangguo@chromium.org,tebbi@chromium.org,ishell@chromium.org,bmeurer@chromium.org
      
      Change-Id: Ic741c3d407d4257a8c86b3082b9a19e33dc89215
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7065, v8:8171
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1222368Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55839}
      350dfb62
    • Benedikt Meurer's avatar
      Reland "[objects] Change String::length field to uint32_t." · a03cec2c
      Benedikt Meurer authored
      This is a reland of 1f1eb625, the
      breakage on the GCStress bot seems to be unrelated (maybe flushed
      out by this change). We decided to reland to figure out whether it's
      a random flake or really triggered by this particular change.
      
      Original change's description:
      > [objects] Change String::length field to uint32_t.
      >
      > This changes the Name::hash_field and Symbol::flags to uint32_t as
      > well, so that both Symbols and Strings consume one fewer word on 64-bit
      > architectures now. More importantly the access to String::length is
      > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      > on 64-bit with pointer compression), so the access should be faster.
      >
      > Bug: v8:7065, v8:8171
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      > Reviewed-on: https://chromium-review.googlesource.com/1221288
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55825}
      
      Bug: v8:7065, v8:8171
      Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org, ulan@chromium.org
      Change-Id: I2be24ac018591c04c826e7e8db82e007b738d156
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1222308Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55838}
      a03cec2c
    • Benedikt Meurer's avatar
      Revert "Reland "[objects] Change String::length field to uint32_t."" · bd69d64d
      Benedikt Meurer authored
      This reverts commit df6157ae.
      
      Reason for revert: trybots didn't rerun :-/
      
      Original change's description:
      > Reland "[objects] Change String::length field to uint32_t."
      > 
      > This is a reland of 1f1eb625, the
      > breakage on the GCStress bot seems to be unrelated (maybe flushed
      > out by this change). We decided to reland to figure out whether it's
      > a random flake or really triggered by this particular change.
      > 
      > Original change's description:
      > > [objects] Change String::length field to uint32_t.
      > >
      > > This changes the Name::hash_field and Symbol::flags to uint32_t as
      > > well, so that both Symbols and Strings consume one fewer word on 64-bit
      > > architectures now. More importantly the access to String::length is
      > > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      > > on 64-bit with pointer compression), so the access should be faster.
      > >
      > > Bug: v8:7065, v8:8171
      > > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      > > Reviewed-on: https://chromium-review.googlesource.com/1221288
      > > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#55825}
      > 
      > Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org
      > Bug: v8:7065, v8:8171
      > Change-Id: I3c7d0b00abb15fa98ab622f9ecd8602fc798cbc3
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/1221290
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55836}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,tebbi@chromium.org,ishell@chromium.org,bmeurer@chromium.org
      
      Change-Id: Ieaf3be31166abb02e37370ad846c38fa3d114693
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7065, v8:8171
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1222306Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55837}
      bd69d64d
    • Benedikt Meurer's avatar
      Reland "[objects] Change String::length field to uint32_t." · df6157ae
      Benedikt Meurer authored
      This is a reland of 1f1eb625, the
      breakage on the GCStress bot seems to be unrelated (maybe flushed
      out by this change). We decided to reland to figure out whether it's
      a random flake or really triggered by this particular change.
      
      Original change's description:
      > [objects] Change String::length field to uint32_t.
      >
      > This changes the Name::hash_field and Symbol::flags to uint32_t as
      > well, so that both Symbols and Strings consume one fewer word on 64-bit
      > architectures now. More importantly the access to String::length is
      > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      > on 64-bit with pointer compression), so the access should be faster.
      >
      > Bug: v8:7065, v8:8171
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      > Reviewed-on: https://chromium-review.googlesource.com/1221288
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55825}
      
      Tbr: tebbi@chromium.org, yangguo@chromium.org, ishell@chromium.org
      Bug: v8:7065, v8:8171
      Change-Id: I3c7d0b00abb15fa98ab622f9ecd8602fc798cbc3
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1221290
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55836}
      df6157ae
    • Leszek Swirski's avatar
      Revert "[objects] Change String::length field to uint32_t." · 4bbb7c4e
      Leszek Swirski authored
      This reverts commit 1f1eb625.
      
      Reason for revert: GC Stress failure (https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/21311) 
      
      Original change's description:
      > [objects] Change String::length field to uint32_t.
      > 
      > This changes the Name::hash_field and Symbol::flags to uint32_t as
      > well, so that both Symbols and Strings consume one fewer word on 64-bit
      > architectures now. More importantly the access to String::length is
      > always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      > on 64-bit with pointer compression), so the access should be faster.
      > 
      > Bug: v8:7065, v8:8171
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      > Reviewed-on: https://chromium-review.googlesource.com/1221288
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55825}
      
      TBR=yangguo@chromium.org,tebbi@chromium.org,ishell@chromium.org,bmeurer@chromium.org
      
      Change-Id: I73f3200902f9d52e5664d48c938e37d9dfb7bce7
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7065, v8:8171
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1221706Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55826}
      4bbb7c4e
    • Benedikt Meurer's avatar
      [objects] Change String::length field to uint32_t. · 1f1eb625
      Benedikt Meurer authored
      This changes the Name::hash_field and Symbol::flags to uint32_t as
      well, so that both Symbols and Strings consume one fewer word on 64-bit
      architectures now. More importantly the access to String::length is
      always a 32-bit field load now, even with 31-bit Smis (i.e. on ARM or
      on 64-bit with pointer compression), so the access should be faster.
      
      Bug: v8:7065, v8:8171
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I5523deb1f84ece91fa2fea775d50318bd1300493
      Reviewed-on: https://chromium-review.googlesource.com/1221288
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55825}
      1f1eb625
  5. 10 Sep, 2018 1 commit
  6. 07 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a pure StringConcat operator. · e56b6d24
      Benedikt Meurer authored
      This replaces the previous CheckStringAdd operator which deopts in case
      the combined length overflows with a dedicated pure StringConcat operator.
      This operator is similar to NewConsString in that it takes the resulting
      length plus the two input strings. The operator relies on the length
      being checked explicitly by the surrounding code instead of baking the
      check into the operator itself. This way TurboFan can eliminate
      redundant/unnecessary StringConcat operations, since they are pure now.
      
      This also unifies the treatment of string addition in JSTypedLowering,
      and generalizes the StringLength constant-folding to apply to more cases
      not just the JSAdd cases inside JSTypedLowering.
      
      Bug: v8:7902, v8:8015
      Change-Id: I987ec39815a9464fd5fd9c4f7b26b709f94f2b3f
      Reviewed-on: https://chromium-review.googlesource.com/1213205Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55725}
      e56b6d24
  7. 29 Aug, 2018 1 commit
    • Maya Lekova's avatar
      [turbofan] Introduce a CheckStringAdd node instead of cons string lowering · 6a7872b7
      Maya Lekova authored
      The new node is introduced for literal string addition and calling
      String.prototype.concat in the typed lowering phase. It later might get optimized
      away during redundancy elimination, keeping the performance of already existing
      benchmarks with string addition. In case the operation is about to throw
      (due to too long string being constructed) we just deoptimize, reusing
      the interpreter logic for creating the error.
      
      Modify relevant mjsunit and unit tests for string concatenation.
      
      Bug: v8:7902
      Change-Id: Ie97d39534df4480fa8d4fe3ba276d02ed5e750e3
      Reviewed-on: https://chromium-review.googlesource.com/1193342
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55482}
      6a7872b7
  8. 27 Aug, 2018 1 commit
  9. 23 Aug, 2018 1 commit
  10. 22 Aug, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Support HOLEY_DOUBLE_ELEMENTS for Array#find() and findIndex(). · 11261f42
      Benedikt Meurer authored
      This adds the missing support for HOLEY_DOUBLE_ELEMENTS to both
      `Array#find()` and `Array#findIndex()`. The implementation just deopts
      whenever it hits a double hole. In order to prevent deoptimization
      loops we add feedback to the CheckFloat64Hole operator, which also
      addresses the TODO in the `%ArrayIteratorPrototype%.next()` lowering.
      
      This provides a speed-up of up to 8x in microbenchmarks when using
      `Array#find()` or `Array#findIndex()` on HOLEY_DOUBLE_ELEMENTS arrays.
      
      Bug: chromium:791045, v8:1956, v8:6587, v8:7165, v8:8015
      Change-Id: I1be22d3fcba56c676a81dc31a9042f8123ef3a55
      Reviewed-on: https://chromium-review.googlesource.com/1183906Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55321}
      11261f42
  11. 20 Aug, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Improve CheckedInt32Mod lowering. · 35974e2d
      Benedikt Meurer authored
      The CheckedInt32Mod lowering in the EffectControlLinearizer wasn't
      playing well with subsequent optimizations in the MachineOperatorReducer
      especially due to the use of Int32Mod, which introduces another (floating)
      diamond in the MachineOperatorReducer. Switching to Uint32Mod and explicit
      sign handling fixes the problem, plus we also do the mask trick in the
      case where the left hand side is negative now.
      
      With this change the performance on the benchmark mentioned in the bug
      report goes from
      
        console.timeEnd: binary, 1872.346000
        console.timeEnd: modulo, 5967.464000
        console.timeEnd: binary, 6006.789000
        console.timeEnd: modulo, 6293.496000
        console.timeEnd: binary, 5969.264000
        console.timeEnd: modulo, 6291.874000
      
      to
      
        console.timeEnd: binary, 1876.464000
        console.timeEnd: modulo, 5846.643000
        console.timeEnd: binary, 5962.545000
        console.timeEnd: modulo, 5972.639000
        console.timeEnd: binary, 5958.221000
        console.timeEnd: modulo, 5973.171000
      
      so even the peak performance of the modulus is now mostly the same as
      the binary bitwise and.
      
      Bug: v8:8069
      Change-Id: Iaf3828fc0f6c53352367e8bf6c42534f8b13bfb3
      Reviewed-on: https://chromium-review.googlesource.com/1180971Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55211}
      35974e2d
  12. 14 Aug, 2018 4 commits
    • Benedikt Meurer's avatar
      [turbofan] Further optimize DataView accesses. · 5fecd146
      Benedikt Meurer authored
      This adds support for unaligned load/store access to the DataView
      backing store and uses byteswap operations to fix up the endianess
      when necessary. This changes the Word32ReverseBytes operator to be
      a required operator and adds the missing support on the Intel and
      ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
      is also mandatory now).
      
      This further improves the performance on the dataviewperf.js test
      mentioned in the tracking bug by up to 40%, and at the same time
      reduces the code complexity in the EffectControlLinearizer.
      
      Bug: chromium:225811
      Change-Id: I7c1ec826faf46a144a5a9068f8f815a5fd040997
      Reviewed-on: https://chromium-review.googlesource.com/1174252Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55111}
      5fecd146
    • Benedikt Meurer's avatar
      Revert "[turbofan] Properly zero-extend indices on 64-bit architectures." · 4c98815a
      Benedikt Meurer authored
      This reverts commit 6c7c81e0.
      
      Reason for revert: Dependent CL was reverted.
      
      Original change's description:
      > [turbofan] Properly zero-extend indices on 64-bit architectures.
      > 
      > This was an oversight from the previous CL. It doesn't really matter
      > with the current code generation pattern, since the upper bits of the
      > index will always be zero, but that might change in the future.
      > 
      > Bug: chromium:225811
      > Change-Id: I568a0824cad9ce9b73a56decc15d146c7dc675a1
      > Reviewed-on: https://chromium-review.googlesource.com/1174111
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55104}
      
      TBR=jarin@chromium.org,bmeurer@chromium.org
      
      Change-Id: Ib344609b0c4734c6512e6be287a5b7f80bc3f603
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:225811
      Reviewed-on: https://chromium-review.googlesource.com/1174232Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55109}
      4c98815a
    • Leszek Swirski's avatar
      Revert "[turbofan] Further optimize DataView accesses." · 6a62d88e
      Leszek Swirski authored
      This reverts commit c46915b9.
      
      Reason for revert: Disasm failures https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/21727 
      
      Original change's description:
      > [turbofan] Further optimize DataView accesses.
      > 
      > This adds support for unaligned load/store access to the DataView
      > backing store and uses byteswap operations to fix up the endianess
      > when necessary. This changes the Word32ReverseBytes operator to be
      > a required operator and adds the missing support on the Intel and
      > ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
      > is also mandatory now).
      > 
      > This further improves the performance on the dataviewperf.js test
      > mentioned in the tracking bug by up to 40%, and at the same time
      > reduces the code complexity in the EffectControlLinearizer.
      > 
      > Bug: chromium:225811
      > Change-Id: I296170b828c2ccc1c317ed37840b564aa14cdec2
      > Reviewed-on: https://chromium-review.googlesource.com/1172777
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55099}
      
      TBR=sigurds@chromium.org,bmeurer@chromium.org
      
      Change-Id: If7a62e3a1a4ad26823fcbd2ab6eb4c053ad11c49
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:225811
      Reviewed-on: https://chromium-review.googlesource.com/1174171Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55107}
      6a62d88e
    • Benedikt Meurer's avatar
      [turbofan] Properly zero-extend indices on 64-bit architectures. · 6c7c81e0
      Benedikt Meurer authored
      This was an oversight from the previous CL. It doesn't really matter
      with the current code generation pattern, since the upper bits of the
      index will always be zero, but that might change in the future.
      
      Bug: chromium:225811
      Change-Id: I568a0824cad9ce9b73a56decc15d146c7dc675a1
      Reviewed-on: https://chromium-review.googlesource.com/1174111
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55104}
      6c7c81e0
  13. 13 Aug, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Further optimize DataView accesses. · c46915b9
      Benedikt Meurer authored
      This adds support for unaligned load/store access to the DataView
      backing store and uses byteswap operations to fix up the endianess
      when necessary. This changes the Word32ReverseBytes operator to be
      a required operator and adds the missing support on the Intel and
      ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
      is also mandatory now).
      
      This further improves the performance on the dataviewperf.js test
      mentioned in the tracking bug by up to 40%, and at the same time
      reduces the code complexity in the EffectControlLinearizer.
      
      Bug: chromium:225811
      Change-Id: I296170b828c2ccc1c317ed37840b564aa14cdec2
      Reviewed-on: https://chromium-review.googlesource.com/1172777
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55099}
      c46915b9
  14. 12 Jul, 2018 1 commit
  15. 09 Jul, 2018 1 commit
    • Théotime Grohens's avatar
      [turbofan] Add DataView setters in TurboFan · c4323e08
      Théotime Grohens authored
      This CL completes the implementation of DataView prototype methods
      in TurboFan, by implementing the Uint8, Int8, Uint16, Int16,
      Uint32, Int32, Float32 and Float64 setters.
      
      DataView performance is now ahead of the equivalent TypedArray wrapper,
      and is now expected to at least match TypedArray performance in
      the general case as well.
      
      This CL also adds a test file in the compiler directory, to make
      sure that the setters actually behave correctly.
      
      Change-Id: I4ad4341c6b9b9d461348b62216f37a73abe321e8
      Reviewed-on: https://chromium-review.googlesource.com/1128867Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Théotime Grohens <theotime@google.com>
      Cr-Commit-Position: refs/heads/master@{#54331}
      c4323e08
  16. 06 Jul, 2018 1 commit
  17. 05 Jul, 2018 1 commit
  18. 04 Jul, 2018 1 commit
  19. 21 Jun, 2018 1 commit
  20. 18 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      Make CallInterfaceDescriptor isolate-independent · 3cb376dc
      Clemens Hammacher authored
      Currently each isolate stores its own array of
      {CallInterfaceDescriptorData}. This array has size 173, and each entry
      has 40 bytes. That's already 7kB per isolate.
      Additionally, each {CallInterfaceDescriptorData} allocates two
      heap-allocated arrays, which probably add up to more than the static
      size of the {CallInterfaceDescriptorData}. Note that all the
      {CallInterfaceDescriptorData} instances are initialized eagerly on
      isolate creation.
      
      Since {CallInterfaceDescriptor} is totally isolate independent itself,
      this CL refactors the current design to avoid a copy of them per
      isolate, and instead shares them process-wide. Still, we need to free
      the allocated heap arrays when the last isolate dies to avoid leaks.
      This can probably be refactored later by statically initializing more
      and avoiding the heap allocations all together.
      
      This refactoring will also allow us to use {CallInterfaceDescriptor}s
      from wasm background compilation threads, which are not bound to any
      isolate.
      
      R=mstarzinger@chromium.org, titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494
      Reviewed-on: https://chromium-review.googlesource.com/1100879
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53803}
      3cb376dc
  21. 05 Jun, 2018 1 commit
  22. 29 May, 2018 1 commit
  23. 24 May, 2018 1 commit
  24. 18 May, 2018 1 commit
  25. 30 Apr, 2018 2 commits
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored
      The idea is to mark all the branches and loads participating in array
      bounds checks, and let them contribute-to/use the poisoning register.
      In the code, the marks for array indexing operations now contain
      "Critical" in their name. By default (--untrusted-code-mitigations),
      we only instrument the "critical" operations with poisoning.
      
      With that in place, we also remove the array masking approach based
      on arithmetic.
      
      Since we do not propagate the poison through function calls,
      we introduce a node for poisoning an index that is passed through
      function call - the typical example is the bounds-checked index
      that is passed to the CharCodeAt builtin.
      
      Most of the code in this CL is threads through the three levels of
      protection (safe, critical, unsafe) for loads, branches and flags.
      
      Bug: chromium:798964
      
      Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
      Reviewed-on: https://chromium-review.googlesource.com/995413
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
    • Jaroslav Sevcik's avatar
      [turbofan] Remove the hacky Type::operator-> overload · ba616de1
      Jaroslav Sevcik authored
      This removes Type::operator-> which was used to split the change that
      removed undefined misuse of Type* to represent integers.
      
      Bug: v8:3770
      Change-Id: I9a5bce5ccdc75461a7b939b4070cb58fe6040d99
      Reviewed-on: https://chromium-review.googlesource.com/1033736Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52878}
      ba616de1
  26. 28 Apr, 2018 1 commit
  27. 25 Apr, 2018 2 commits
    • Sigurd Schneider's avatar
      [turbofan] Move Date.now/Date.p.getTime to JSCallReducer · 64351075
      Sigurd Schneider authored
      This CL also introduces an effect dependent simplified operator
      DateNow and associated lowerings.
      
      Bug: v8:7340, v8:7250
      Change-Id: Icd4a8c3c45a8dbe7ef490fc3ee68c0c68bbed011
      Reviewed-on: https://chromium-review.googlesource.com/1024836
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52782}
      64351075
    • Andreas Haas's avatar
      Reland: [refactoring] Remove the isolate from signatures of ExternalReferences · 2a3c2c73
      Andreas Haas authored
      I missed one required change which was hidden behind an #if. The fix is in
      the diff between Patch 1 and Patch 3.
      
      Original message:
      In this CL I remove the isolate from signatures of ExternalReference
      accessor functions where the isolate is not used. The uses of the
      isolate were already removed in previous CLs.
      
      Changes:
      * I split the ExternalReference list in external-reference.h into
      those which need the isolate for initialization and those which do not.
      
      * I removed the public constructors and replaced them by
        ExternalReference::Create(). The reason is to separate external
        creation more clearly from internal creation, because externally
        created ExternalReferences sometimes need redirection, whereas
        internally created ExternalReferences are just stored as they are.
        In addition, by removing the isolate from the signature of the
        public constructors, they suddenly exactly matched the interal
        constructor.
      
      * Replace all uses of the public constructors with
        ExternalReference::Create().
      
      * Remove the isolate from all call sites where necessary.
      
      
      This is a step towards making WebAssembly compilation independent of
      the isolate.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:7570
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057
      Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52777}
      2a3c2c73