1. 05 Feb, 2021 1 commit
    • Paolo Severini's avatar
      [compiler] Re-reland "Faster JS-to-Wasm calls" · 831fa62b
      Paolo Severini authored
      This is a reland of 6ada6a90
      
      - Fixed a GC issue
        https://bugs.chromium.org/p/v8/issues/detail?id=11335:
        GC expected all arguments on the stack from code with
        CodeKind::TURBOFAN to be tagged objects. This is not the case now with
        inlined Wasm calls, and this information can be passed in
        SafepointEntry for each call site.
      
      - Disabled JS-to-Wasm inlining for calls inside try/catch.
      
      For more details, see updated doc:
      https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      
      Bug: v8:11092
      
      
      Original change's description:
      > Reland "Faster JS-to-Wasm calls"
      >
      > This is a reland of 860fcb1b
      >
      > - Disabled the tests for this feature in V8-lite mode (the original
      > change broke V8-lite tests).
      > - Also modified test console-profile-wasm.js that was brittle with this
      > change because it assumed that there was always a JS-to-Wasm wrapper
      > but this is not the case when the TurboFan compilation completes before
      > the Liftoff-compiled code starts to run.
      >
      > More changes in Patchset 8:
      >
      > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      > into a new phase, wasm-inlining that reuses the JSInliner reducer.
      > The doc
      > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      > describes the new logic.
      >
      > - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      > the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      > this should solve the problem we had inlining the calls in functions
      > that can throw exception.
      
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid
      > generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      
      Bug: v8:11092
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72541}
      831fa62b
  2. 02 Feb, 2021 1 commit
  3. 01 Feb, 2021 1 commit
  4. 29 Jan, 2021 1 commit
  5. 27 Jan, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Fix data race in lazy compilation · 591db5d9
      Clemens Backes authored
      Instead of updating the detected features set directly, use the
      synchronized {OnCompilationStopped} method.
      In order to avoid this error in the future, the whole
      {detected_features()} getter is removed, as it returns a pointer which
      can only be accessed when holding the mutex anyway. Also, the refactored
      code was the only user of this dangerous method.
      
      Drive-by: Pass the WasmFeatures set by value, since it's just an
      EnumSet.
      Drive-by 2: Remove a print line from the regression test which can be
      confusing if the test is picked up again by foozzie.
      
      R=ahaas@chromium.org
      CC=zhin@chromium.org
      
      Bug: v8:11357
      Change-Id: I75b5c8f35983d2bc1fd2b61adcb2ecfc18564f39
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653226Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72375}
      591db5d9
  6. 26 Jan, 2021 2 commits
  7. 25 Jan, 2021 1 commit
  8. 22 Jan, 2021 2 commits
    • Paolo Severini's avatar
      Revert "Reland "Faster JS-to-Wasm calls"" · 51ecfaec
      Paolo Severini authored
      This reverts commit 6ada6a90.
      
      Reason for revert: Revert for link issue:
      https://bugs.chromium.org/p/v8/issues/detail?id=11335
      
      Original change's description:
      > Reland "Faster JS-to-Wasm calls"
      >
      > This is a reland of 860fcb1b
      >
      > - Disabled the tests for this feature in V8-lite mode (the original
      > change broke V8-lite tests)
      > - Also modified test console-profile-wasm.js that was brittle with this
      > change because it assumed that there was always a JS-to-Wasm wrapper
      > but this is not the case when the TurboFan compilation completes before
      > the Liftoff-compiled code starts to run.
      >
      > More changes in Patchset 8:
      >
      > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      > into a new phase, wasm-inlining that reuses the JSInliner reducer.
      > The doc
      > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      > describes the new logic.
      >
      > - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      > the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      > this should solve the problem we had inlining the calls in functions
      > that can throw exception.
      >
      >
      > Original change's description:
      > > Faster JS-to-Wasm calls
      > >
      > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      > >
      > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > > the basis of the signature of a Wasm function to call, and whose task
      > > is to:
      > > - set "thread_in_wasm_flag" to true
      > > - convert the arguments from tagged types into Wasm native types
      > > - calculate the address of the Wasm function to call and call it
      > > - convert back the result from Wasm native types into tagged types
      > > - reset "thread_in_wasm_flag" to false.
      > >
      > > This CL tries to improve the performance of JS-to-Wasm calls by
      > > inlining the code of the JS-to-Wasm wrappers in the call site.
      > >
      > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > > this kind of calls. A 'JSWasmCall' node is associated to
      > > WasmCallParameters, which contain information about the signature of
      > > the Wasm function to call.
      > >
      > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > > of the Wasm function, when the conversion is not necessary.
      > > The actual inlining of the graph generated for this wrapper happens in
      > > the simplified-lowering phase.
      > >
      > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > > lazy deoptimizations that can happen if the Wasm function callee calls
      > > back some JS code that invalidates the compiled JS caller function.
      > >
      > > Bug: v8:11092
      > > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > > Cr-Commit-Position: refs/heads/master@{#71824}
      >
      > Bug: v8:11092
      > Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      > Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72147}
      
      Tbr: ahaas@chromium.org, jgruber@chromium.org
      Bug: v8:11092, v8:11335
      Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72253}
      51ecfaec
    • Andreas Haas's avatar
      [wasm] Implement pushing of externref parameters on the stack · 3a8a7e61
      Andreas Haas authored
      On x64, reference types where not handled yet in LiftoffAssembler::push.
      Note that the values pushed on the stack there do not have to be
      handled by a safepoint. The reason is that stack parameters in general
      are handled separately from safepoints.
      
      R=thibaudm@chromium.org
      
      Bug: chromium:1168116
      Change-Id: Ie62479c13839f0ba240d0e41fa76d07a2cc48881
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642263Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72252}
      3a8a7e61
  9. 20 Jan, 2021 1 commit
  10. 13 Jan, 2021 1 commit
  11. 11 Jan, 2021 1 commit
    • Andreas Haas's avatar
      [wasm][liftoff] Delay use counter decrement of PeekToRegister · 48ead1a8
      Andreas Haas authored
      This CL fixes a bug in the code generation for I32AtomicCompareExchange
      in Liftoff on ia32. The problem is the inconsistency that
      LiftoffAssembler::PeekToRegister(...) introduces to the cache state.
      PeekToRegister loads the value from the value stack into a register, but
      does not pop the value off the stack. When the value was already stored
      in a register, the use counter of that register gets decreased, even
      though the value is still on the stack.
      
      The problem arises when this register later gets reused, which is
      necessary unfortunately on ia32. When SpillRegister is called for this
      register, all stack values that are stored in this register get written
      to memory. SpillRegister uses the use counter of the register to detect
      when the register was spilled to all stack slots that were cached by
      this register. However, as described above, the value stack and the use
      counter are inconsistent at that moment, so SpillRegister finishes
      early and does not spill the register to all stack values, and this
      causes the bug later.
      
      With this CL the decrement of the use counter gets delayed until when
      the value actually gets popped off the stack.
      
      R=clemensb@chromium.org
      
      Bug: chromium:1145135
      Change-Id: I07cb256a7e5135dbce41b246c120650635ad2758
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602464Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72018}
      48ead1a8
  12. 08 Jan, 2021 1 commit
    • Zhi An Ng's avatar
      [wasm-simd] Fix loading fp pair registers · 8c698702
      Zhi An Ng authored
      We were incorrectly clearing the high reg from the list of regs to load.
      The intention was to prevent double (and incorrect) loading - loading
      128 bits from the low fp and the loading 128 bits from the high fp.
      But this violates the assumption that the two regs in a pair would be
      set or unset at the same time.
      
      The fix here is to introduce a new enum for register loads, a nop, which
      does nothing. The high fp of the fp pair will be tied to this nop, so as
      we iterate down the reglist, we load 128 bits using the low fp, then
      don't load anything for the high fp.
      
      Bug: chromium:1161654
      Change-Id: If2ea79132b78623e5990237c60cf0883d9a8223f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617380Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71976}
      8c698702
  13. 07 Jan, 2021 1 commit
  14. 06 Jan, 2021 1 commit
  15. 05 Jan, 2021 1 commit
  16. 03 Dec, 2020 2 commits
  17. 02 Dec, 2020 1 commit
  18. 30 Nov, 2020 1 commit
  19. 27 Nov, 2020 1 commit
  20. 18 Nov, 2020 1 commit
  21. 10 Nov, 2020 2 commits
  22. 09 Nov, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][liftoff] Fix register usage for i64_addi · 89ca48c9
      Clemens Backes authored
      The arm implementation made the assumption that the {lhs} and {dst}
      registers are either the same, or there is no overlap. This assumption
      does not hold.
      ia32 on the other hand has a lot of complicated logic (and unnecessary
      code generation) for different cases of overlap.
      
      This CL fixes the arm issue *and* simplifies the ia32 logic by making
      the arm assumption hold, and using it to eliminate special handling on
      ia32.
      
      R=thibaudm@chromium.org
      
      Bug: chromium:1146861
      Change-Id: I8753c2ed70349e735c03293130c899c0c8a3a671
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526388Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71060}
      89ca48c9
  23. 29 Oct, 2020 1 commit
  24. 26 Oct, 2020 1 commit
    • Andreas Haas's avatar
      [wasm] Deserialized code is marked with top-tier-finished · a9f376aa
      Andreas Haas authored
      For deserialized modules the compilation state was not set to
      kFinishedTopTierCompilation and co. A consequence was that code that
      required top tier compilation to be finished to block indefinitely.
      
      With this CL the compilation state is initialized properly.
      
      I tested this CL locally with the regression test mentioned in the bug
      tracker issue. However, this regression test required to run this test
      twice in separate processes. It would be possible to write a regression
      test for this that runs on the bots, but I considered it not worth it.
      
      R=clemensb@chromium.org
      
      Bug: v8:11024
      Change-Id: Ib4e75eae03fab13a3ff013118fc1f33a1278b33f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494930Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70757}
      a9f376aa
  25. 22 Oct, 2020 1 commit
  26. 21 Oct, 2020 1 commit
  27. 19 Oct, 2020 1 commit
    • Thibaud Michaud's avatar
      [codegen] Skip invalid optimization in tail calls · 7506e063
      Thibaud Michaud authored
      Preparing for tail call is usually done by emitting the gap moves and
      then moving the stack pointer to its new position. An optimization
      consists in moving the stack pointer first and transforming some of the
      moves into pushes. In the attached case it looks like this (arm):
      
      138  add sp, sp, #40
      13c  str r6, [sp, #-4]!
      140  str r6, [sp, #-4]!
      144  str r6, [sp, #-4]!
      148  str r6, [sp, #-4]!
      14c  str r6, [sp, #-4]!
      ...
      160  vldr d1, [sp - 4*3]
      
      The last line is a gap reload, but because the stack pointer was already
      moved, the slot is now below the stack pointer. This is invalid and
      triggers this DCHECK:
      
      Fatal error in ../../v8/src/codegen/arm/assembler-arm.cc, line 402
      Debug check failed: 0 <= offset (0 vs. -12).
      
      A comment already explains that we skip the optimization if the gap
      contains stack moves to prevent this, but the code only checks for
      non-FP slots. This is fixed by replacing "source.IsStackSlot()" with
      "source.IsAnyStackSlot()":
      
      108  vldr d1, [sp + 4*2]
      ...
      118  str r0, [sp, #+36]
      11c  str r0, [sp, #+32]
      120  str r0, [sp, #+28]
      124  str r0, [sp, #+24]
      128  str r0, [sp, #+20]
      ...
      134  add sp, sp, #20
      
      R=jgruber@chromium.org
      
      Bug: chromium:1137608
      Change-Id: If2b85dde49bf31a6bd3f5e0255407f9390727f9d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474784Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70603}
      7506e063
  28. 13 Oct, 2020 1 commit
  29. 29 Sep, 2020 1 commit
  30. 25 Sep, 2020 1 commit
  31. 24 Sep, 2020 1 commit
  32. 22 Sep, 2020 1 commit
  33. 18 Sep, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland^5 "[flags] warn about contradictory flags" · 0832a109
      Tobias Tebbi authored
      This is a reland of 2000aea5
      Changes compared to last reland:
      - Add rule in variants.py for --enable_experimental_regexp_engine.
      - Make sure --abort-on-contradictory-flags works as well as --fuzzing
        to disable the checking for fuzzers, including for d8 flags.
      
      Original change's description:
      > Reland^4 "[flags] warn about contradictory flags"
      >
      > This is a reland of 0ba115e6
      > Changes compared to last reland:
      > - Fix Python code trying to write to expected_outcomes, which is now a
      >   computed property.
      > - Fix remaining place in d8.cc that ignored the --fuzzing flag.
      > - Expect flag contradictions for --cache in code_serializer variant.
      >
      > Original change's description:
      > > Reland^3 "[flags] warn about contradictory flags"
      > >
      > > Changes:
      > > - Also allow second parameter influenced by --cache to be reassigned.
      > > - Fix --stress-opt to only --always-opt in the last iteration as before.
      > >
      > > 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}
      > >
      > > Bug: v8:10577
      > > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      > > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      > > Change-Id: I4a69dc57a102782cb453144323e3752ac8278624
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
      > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#69433}
      >
      > Change-Id: Ib6d2aeb495210f581ac671221c265df58e8e5e70
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398640
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69954}
      
      Bug: v8:10577
      TBR: clemensb@chromium.org, tmrts@chromium.org
      Change-Id: Iab2d32cdcc2648934fc52255ccf3ae3ec9ca4d9b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416386Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70000}
      0832a109
  34. 16 Sep, 2020 2 commits
    • Bill Budge's avatar
      Revert "Reland^4 "[flags] warn about contradictory flags"" · a0e38f31
      Bill Budge authored
      This reverts commit 2000aea5.
      
      Reason for revert: Breaks NumFuzz.
      
      Original change's description:
      > Reland^4 "[flags] warn about contradictory flags"
      > 
      > This is a reland of 0ba115e6
      > Changes compared to last reland:
      > - Fix Python code trying to write to expected_outcomes, which is now a
      >   computed property.
      > - Fix remaining place in d8.cc that ignored the --fuzzing flag.
      > - Expect flag contradictions for --cache in code_serializer variant.
      > 
      > Original change's description:
      > > Reland^3 "[flags] warn about contradictory flags"
      > >
      > > Changes:
      > > - Also allow second parameter influenced by --cache to be reassigned.
      > > - Fix --stress-opt to only --always-opt in the last iteration as before.
      > >
      > > 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}
      > >
      > > Bug: v8:10577
      > > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      > > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      > > Change-Id: I4a69dc57a102782cb453144323e3752ac8278624
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
      > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#69433}
      > 
      > Change-Id: Ib6d2aeb495210f581ac671221c265df58e8e5e70
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398640
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69954}
      
      TBR=clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
      
      Change-Id: I2dc80bcad9f74c29298902e01939e7e7f3336cf6
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2415133Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69959}
      a0e38f31
    • Tobias Tebbi's avatar
      Reland^4 "[flags] warn about contradictory flags" · 2000aea5
      Tobias Tebbi authored
      This is a reland of 0ba115e6
      Changes compared to last reland:
      - Fix Python code trying to write to expected_outcomes, which is now a
        computed property.
      - Fix remaining place in d8.cc that ignored the --fuzzing flag.
      - Expect flag contradictions for --cache in code_serializer variant.
      
      Original change's description:
      > Reland^3 "[flags] warn about contradictory flags"
      >
      > Changes:
      > - Also allow second parameter influenced by --cache to be reassigned.
      > - Fix --stress-opt to only --always-opt in the last iteration as before.
      >
      > 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}
      >
      > Bug: v8:10577
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      > Change-Id: I4a69dc57a102782cb453144323e3752ac8278624
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69433}
      
      Change-Id: Ib6d2aeb495210f581ac671221c265df58e8e5e70
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398640
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69954}
      2000aea5
  35. 10 Sep, 2020 1 commit