1. 17 Aug, 2020 1 commit
  2. 14 Aug, 2020 1 commit
  3. 13 Aug, 2020 2 commits
  4. 11 Aug, 2020 4 commits
    • Ng Zhi An's avatar
      Reland "[wasm-simd][arm] Use vmov to move all ones to register" · 9b9c6b0e
      Ng Zhi An authored
      This is a reland of 57242a05
      
      no-sse4.1 builds were failing due to missing simd-scalar-lowering
      for s128.const, this reland adds that implementation.
      
      Original change's description:
      > [wasm-simd][arm] Use vmov to move all ones to register
      >
      > vceq(dst, dst, dst) does not seem to always set the register to all
      > ones. The right way should be be to use vmov (immediate) anyway. This
      > was not supported in the assembler yet, so we need changes to the
      > assembler, diassembler, and simulator.
      >
      > There is an unfortunate fork in logic in the simulator, due to the way
      > the switches are set up, vmov (imm) logic is duplicated across two
      > different cases, because the switch looks at the top bit of the
      > immediate. Refactoring this will be a bigger change that is irrelevant
      > for this bug, so I'm putting that off for now. Instead we extract the
      > core of vmov (imm) into helpers and call it in the two cases.
      >
      > Bug: chromium:1112124
      > Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Bill Budge <bbudge@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69315}
      
      Bug: chromium:1112124
      Change-Id: Id450e5cea41f7a569e49be8386a7788ca8f00658
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346937Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69346}
      9b9c6b0e
    • Bill Budge's avatar
      Revert "Reland^2 "[flags] warn about contradictory flags"" · 7e932233
      Bill Budge authored
      This reverts commit 0ba115e6.
      
      Reason for revert: Breaks test on TSAN - block-conflicts
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/14230
      
      Original change's description:
      > Reland^2 "[flags] warn about contradictory flags"
      > 
      > This is a reland of d8f8a7e2
      > Change compared to last reland:
      > - Do not check for d8 flag contradictions in the presence of --fuzzing
      > - Allow identical re-declaration of --cache=*
      > 
      > Original change's description:
      > > Reland "[flags] warn about contradictory flags"
      > >
      > > This is a reland of b8f91666
      > > Difference to previous CL: Additional functionality to specify
      > > incompatible flags based on GN variables and extra-flags, used
      > > to fix the issues that came up on the waterfall.
      > >
      > > This also changes the rules regarding repeated flags: While
      > > explicitly repeated flags are allowed for boolean values as long
      > > as they are identical, repeated flags or explicit flags in the
      > > presence of an active implication are disallowed for non-boolean
      > > flags. The latter simplifies specifying conflict rules in
      > > variants.py. Otherwise a rule like
      > >
      > > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
      > >   "--gc-interval=*": ["--gc-interval=*"],
      > > }
      > >
      > > wouldn't work because specifying the same GC interval twice
      > > wouldn't actually count as a conflict. This was an issue with
      > > test/mjsunit/wasm/gc-buffer.js, which specifies
      > > --gc-interval=500 exactly like the extra flag by the stress bot.
      > >
      > > Also, this now expands contradictory flags checking to d8 flags
      > > for consistency.
      > >
      > > Original change's description:
      > > > [flags] warn about contradictory flags
      > > >
      > > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
      > > >
      > > > Bug: v8:10577
      > > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
      > > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#68168}
      > >
      > > Bug: v8:10577
      > > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
      > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#68989}
      > 
      > Bug: v8:10577
      > Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69339}
      
      TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
      
      Change-Id: I1454a05e357ddd704db7fb79e51be65d45a9a16e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10577
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2348365Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69341}
      7e932233
    • Tobias Tebbi's avatar
      Reland^2 "[flags] warn about contradictory flags" · 0ba115e6
      Tobias Tebbi authored
      This is a reland of d8f8a7e2
      Change compared to last reland:
      - Do not check for d8 flag contradictions in the presence of --fuzzing
      - Allow identical re-declaration of --cache=*
      
      Original change's description:
      > Reland "[flags] warn about contradictory flags"
      >
      > This is a reland of b8f91666
      > Difference to previous CL: Additional functionality to specify
      > incompatible flags based on GN variables and extra-flags, used
      > to fix the issues that came up on the waterfall.
      >
      > This also changes the rules regarding repeated flags: While
      > explicitly repeated flags are allowed for boolean values as long
      > as they are identical, repeated flags or explicit flags in the
      > presence of an active implication are disallowed for non-boolean
      > flags. The latter simplifies specifying conflict rules in
      > variants.py. Otherwise a rule like
      >
      > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
      >   "--gc-interval=*": ["--gc-interval=*"],
      > }
      >
      > wouldn't work because specifying the same GC interval twice
      > wouldn't actually count as a conflict. This was an issue with
      > test/mjsunit/wasm/gc-buffer.js, which specifies
      > --gc-interval=500 exactly like the extra flag by the stress bot.
      >
      > Also, this now expands contradictory flags checking to d8 flags
      > for consistency.
      >
      > Original change's description:
      > > [flags] warn about contradictory flags
      > >
      > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
      > >
      > > Bug: v8:10577
      > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
      > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#68168}
      >
      > Bug: v8:10577
      > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68989}
      
      Bug: v8:10577
      Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69339}
      0ba115e6
    • Clemens Backes's avatar
      Reland "[wasm] Ensure that only TurboFan code is serialized" · cdd984ef
      Clemens Backes authored
      This is a reland of 60ee70bb.
      The wasm c-api flakes were fixed in https://crrev.com/c/2349293.
      
      Original change's description:
      > [wasm] Ensure that only TurboFan code is serialized
      >
      > We have the implicit assumption that Liftoff code will never be
      > serialized, and we start relying on that when implementing new features
      > (debugging, dynamic tiering).
      >
      > This CL makes the serializer fail if the module contains any Liftoff
      > code. Existing tests are changed to ensure that we fully tiered up
      > before serializing a module (similar to the logic in Chromium).
      > The "wasm-clone-module" test needs to serialize the module before
      > enabling the debugger.
      >
      > Note that chrome currently only serializes a module after it fully
      > tiered up, so that should be fine. If other embedders need the ability
      > to serialize a module in an arbitrary state, we will have to fix this
      > later. With this CL we will be on the safe side though and (gracefully)
      > fail serialization instead of accidentally serializing Liftoff code.
      >
      > R=ahaas@chromium.org
      >
      > Bug: v8:10777
      > Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69276}
      
      Bug: v8:10777
      Change-Id: I2a7c1429812ca46d88a2902b8e0a7b7e3d638b56
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349290Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69335}
      cdd984ef
  5. 10 Aug, 2020 6 commits
  6. 07 Aug, 2020 6 commits
  7. 06 Aug, 2020 7 commits
  8. 05 Aug, 2020 1 commit
  9. 04 Aug, 2020 2 commits
  10. 03 Aug, 2020 2 commits
  11. 31 Jul, 2020 2 commits
    • Mythri A's avatar
      [turboprop] Migrate deprecated maps in dynamic map check operator · 9b9ba19e
      Mythri A authored
      If incoming map is deprecated, generate code to migrate the map. Since
      this involves generating additional code and a call to runtime, we only
      do this if one of the receiver maps was a migration target when
      optimizing this function. If not, we deoptimize and discard the
      optimized code if we see a deprecated map. This is to avoid bailout
      loops when we see deprecated maps.
      
      This change does the following:
      // We generated code to migrate deprecated maps only if one of the maps
      // in feedback vector is a migration target.
      if ( there are migration targets in feedback)
      {
        if (checkMaps fails) {
           if (incoming map is deprecated) {
              migrate the map
              checkMaps with the new map
           } else {
             bailout
           }
        }
      } else {
        if (checkMaps fails)
          bailout;
      }
      
      Bug: v8:10582, v8:9684
      Change-Id: I8a04c77ed209dd2fb0300a783d844f2335a678c8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292231Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69179}
      9b9ba19e
    • Clemens Backes's avatar
      [d8] Fix worker creation near stack limit · 9555464f
      Clemens Backes authored
      If we are near the stack limit, calling the proxy method might not work
      any more. Instead of crashing because of an empty MaybeLocal, handle
      this gracefully.
      
      Drive-by: Minor refactoring in TryGetValue.
      
      R=tebbi@chromium.org
      
      Bug: chromium:1110001
      Change-Id: I07e7773768166b3dbea2e6b75a3ab8b24bfeee53
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332156Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69161}
      9555464f
  12. 29 Jul, 2020 2 commits
  13. 28 Jul, 2020 3 commits
  14. 27 Jul, 2020 1 commit