1. 31 Oct, 2019 1 commit
  2. 23 Oct, 2019 1 commit
    • Michael Starzinger's avatar
      [turbofan] Change {InstructionCode} to uint32_t. · d5ef741f
      Michael Starzinger authored
      The {InstructionCode} is only used to store plain (non-negative) values
      of the {ArchOpcode} enum, or additionally encodes {BitField} values. The
      underlying base type 'U' of a {BitField} is uint32_t. To avoid all the
      numerous implicit conversions between int32_t and uint32_t, this is
      changing the {InstructionCode} so that uint32_t is used exclusively.
      
      R=neis@chromium.org
      BUG=v8:9872
      
      Change-Id: If64107ad9298011e219b4827735eafb51465beb0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869193Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64503}
      d5ef741f
  3. 17 Oct, 2019 1 commit
  4. 24 Sep, 2019 1 commit
  5. 10 Sep, 2019 1 commit
  6. 26 Aug, 2019 1 commit
  7. 23 Aug, 2019 2 commits
  8. 22 Aug, 2019 3 commits
    • Jakob Gruber's avatar
      Reland "[compiler] Track the maximal unoptimized frame size" · 95e26e49
      Jakob Gruber authored
      This is a reland of 1e472c42
      
      No change, this was a speculative revert to unblock the roll.
      
      TBR=jgruber
      
      Original change's description:
      > [compiler] Track the maximal unoptimized frame size
      >
      > This is another step towards considering the unoptimized frame size in
      > stack checks within optimized code.
      >
      > With the changes in this CL, we now keep track of the maximal
      > unoptimized frame size of the function that is currently being
      > compiled. An optimized function may inline multiple unoptimized
      > functions, so a single optimized frame can deopt to multiple
      > frames. The real frame size thus differs in different parts of the
      > optimized function.
      >
      > We only care about the maximal frame size, which we calculate
      > conservatively as an over-approximation, and track in
      > InstructionSelector::max_unoptimized_frame_height_ for now. In future
      > work, this value will be passed on to codegen, where it will be
      > applied as an offset to the stack pointer during the stack check.
      >
      > (The motivation behind this is to avoid stack overflows through deopts,
      > caused by size differences between optimized and unoptimized frames.)
      >
      > Note that this offset only ensure that the topmost optimized frame can
      > deopt without overflowing the stack limit. That's fine, because we only
      > deopt optimized frames one at a time. Other (non-topmost) frames are
      > only deoptimized once they are returned to.
      >
      > Drive-by: Print variable and total frame height in --trace-deopt.
      >
      > Bug: v8:9534
      > Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63330}
      
      Bug: v8:9534
      Change-Id: I686f200e7be1f419e23e50789e11607a0b2886d9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1766645
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63356}
      95e26e49
    • Bill Budge's avatar
      Revert "[compiler] Track the maximal unoptimized frame size" · 98b5c49f
      Bill Budge authored
      This reverts commit 1e472c42.
      
      Reason for revert: Speculative revert, to attempt to fix crashes that block the V8 roll. Example failure run:
      
      https://ci.chromium.org/p/chromium/builders/try/linux-rel/173465
      
      Original change's description:
      > [compiler] Track the maximal unoptimized frame size
      > 
      > This is another step towards considering the unoptimized frame size in
      > stack checks within optimized code.
      > 
      > With the changes in this CL, we now keep track of the maximal
      > unoptimized frame size of the function that is currently being
      > compiled. An optimized function may inline multiple unoptimized
      > functions, so a single optimized frame can deopt to multiple
      > frames. The real frame size thus differs in different parts of the
      > optimized function.
      > 
      > We only care about the maximal frame size, which we calculate
      > conservatively as an over-approximation, and track in
      > InstructionSelector::max_unoptimized_frame_height_ for now. In future
      > work, this value will be passed on to codegen, where it will be
      > applied as an offset to the stack pointer during the stack check.
      > 
      > (The motivation behind this is to avoid stack overflows through deopts,
      > caused by size differences between optimized and unoptimized frames.)
      > 
      > Note that this offset only ensure that the topmost optimized frame can
      > deopt without overflowing the stack limit. That's fine, because we only
      > deopt optimized frames one at a time. Other (non-topmost) frames are
      > only deoptimized once they are returned to.
      > 
      > Drive-by: Print variable and total frame height in --trace-deopt.
      > 
      > Bug: v8:9534
      > Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63330}
      
      TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org
      
      Change-Id: I7b225c30bfc4e1d958276583f512a1ec5fa2b458
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9534
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764626Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63350}
      98b5c49f
    • Jakob Gruber's avatar
      [compiler] Track the maximal unoptimized frame size · 1e472c42
      Jakob Gruber authored
      This is another step towards considering the unoptimized frame size in
      stack checks within optimized code.
      
      With the changes in this CL, we now keep track of the maximal
      unoptimized frame size of the function that is currently being
      compiled. An optimized function may inline multiple unoptimized
      functions, so a single optimized frame can deopt to multiple
      frames. The real frame size thus differs in different parts of the
      optimized function.
      
      We only care about the maximal frame size, which we calculate
      conservatively as an over-approximation, and track in
      InstructionSelector::max_unoptimized_frame_height_ for now. In future
      work, this value will be passed on to codegen, where it will be
      applied as an offset to the stack pointer during the stack check.
      
      (The motivation behind this is to avoid stack overflows through deopts,
      caused by size differences between optimized and unoptimized frames.)
      
      Note that this offset only ensure that the topmost optimized frame can
      deopt without overflowing the stack limit. That's fine, because we only
      deopt optimized frames one at a time. Other (non-topmost) frames are
      only deoptimized once they are returned to.
      
      Drive-by: Print variable and total frame height in --trace-deopt.
      
      Bug: v8:9534
      Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63330}
      1e472c42
  9. 06 Aug, 2019 1 commit
    • Jakob Gruber's avatar
      Move knowledge of frame stack height into the FrameStateDescriptor · 9b24f6ec
      Jakob Gruber authored
      When serializing frame states into translations (later used by
      deopts), we pass certain values, depending on the frame kind, to be
      serialized as the frame height.
      
      This CL moves the calculation of this height value into the
      FrameStateDescriptor. In a follow-up, we may want to simplify the way
      these height values are passed and processed by deopts.
      
      The motivation behind this is to simplify calculation of unoptimized
      stack frame sizes during compilation.
      
      Bug: v8:9534
      Change-Id: I20d2b57a42cea0c238b9c887dba0280f6aad76de
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728609
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63085}
      9b24f6ec
  10. 29 Jul, 2019 3 commits
    • Clemens Hammacher's avatar
      Reland "[utils] Make BitField final" · 0cabc6a0
      Clemens Hammacher authored
      This is a reland of 658ff200
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      Bug: v8:9396, v8:7629
      Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62959}
      0cabc6a0
    • Clemens Hammacher's avatar
      Revert "[utils] Make BitField final" · 753a07db
      Clemens Hammacher authored
      This reverts commit 658ff200.
      
      Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=​yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      TBR=yangguo@chromium.org,clemensh@chromium.org
      
      Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9396, v8:7629
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62958}
      753a07db
    • Clemens Hammacher's avatar
      [utils] Make BitField final · 658ff200
      Clemens Hammacher authored
      We have hundreds of classes that derive from {BitField} without adding
      any functionality. This CL switches all such occurrences to 'using'
      declarations instead.
      
      Before:
        class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      After:
        using MyBitField = BitField<int, 6, 4, MyEnum>;
      
      This might reduce compilation time by reducing the number of existing
      classes.
      
      The old pattern is forbidden now by making {BitField} final.
      
      R=yangguo@chromium.org
      
      Bug: v8:9396, v8:7629
      Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62956}
      658ff200
  11. 31 May, 2019 1 commit
    • Santiago Aboy Solanes's avatar
      [ptr-compr][turbofan][CSA] Adding the CompressedHeapConstant node · a31b36e0
      Santiago Aboy Solanes authored
      CompressedHeapConstant is used in the DecompressionElimination Reducer to
      create compressed HeapConstant values. It won't appear in the graph
      up until that point.
      
      This CL enables back the disabled tests in DecompressionElimination, as
      well as generating the CompressedHeapConstant in that reducer.
      
      The RelocInfo has already been added for x64 but not for arm64. Therefore,
      the x64 version is now doing the mov on 32 bits. The support for ARM will
      come in a following CL, and for now it is doing the mov in 64 bits.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
      Bug: v8:8977, v8:7703, v8:9298
      Change-Id: If0ca4f937cfa60501679e66f6fd5ded2df38f605
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632236Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61950}
      a31b36e0
  12. 24 May, 2019 1 commit
  13. 21 May, 2019 1 commit
  14. 15 May, 2019 1 commit
  15. 01 Apr, 2019 1 commit
  16. 29 Mar, 2019 2 commits
  17. 13 Mar, 2019 1 commit
  18. 21 Feb, 2019 1 commit
    • Stephan Herhut's avatar
      [regalloc] Add two spill modes. · 9b1ab6f8
      Stephan Herhut authored
      This change adds two spilling modes: SpillAtDefinition and SpillDeferred.
      The former is the known spilling mode where we spill at definition. The
      latter spills only in deferred code regions. This is implemented based on
      control flow aware allocation and its invariants.
      
      The effect is mostly the same as splintering with the exception of
      forward looking allocation decisions still being impacted by register
      constraints in deferred code.
      
      Change-Id: Ia708e5765dd095196a8127deb2d8bec950d37e04
      Reviewed-on: https://chromium-review.googlesource.com/c/1437118Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Stephan Herhut <herhut@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59759}
      9b1ab6f8
  19. 13 Feb, 2019 1 commit
  20. 28 Jan, 2019 1 commit
  21. 15 Jan, 2019 1 commit
    • Stephan Herhut's avatar
      [codegen] Align targets of switch in loops · acb896b5
      Stephan Herhut authored
      The blazor benchmark wobbles around by 5% with seemingly unrelated
      changes to the generated code. I suspect this is due to moving
      target adresses of the switch statement for the interpreter.
      
      Generally, it would make sense to align targets for switch statements
      as per general optimization guidelines. To keep code growth in bounds,
      this change only enables this for switch statements inside of loops.
      
      Local measurements show an improvement of around 5% for blazor and
      hopefully the benchmark will be more stable moving forward.
      
      Bug: chromium:919986 chromium:921477
      Change-Id: I69df38f902d4fcc65af9e95a63ca1f7f14e0fa09
      Reviewed-on: https://chromium-review.googlesource.com/c/1411637Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Stephan Herhut <herhut@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58825}
      acb896b5
  22. 27 Dec, 2018 1 commit
  23. 19 Dec, 2018 1 commit
  24. 22 Nov, 2018 1 commit
  25. 21 Nov, 2018 1 commit
  26. 16 Nov, 2018 1 commit
  27. 12 Nov, 2018 1 commit
  28. 17 Oct, 2018 1 commit
  29. 21 Sep, 2018 1 commit
    • Jakob Kummerow's avatar
      Fix building with GCC 7.x and 8.x · 9ed4b965
      Jakob Kummerow authored
      GCC 7.x doesn't like it (-Werror=subobject-linkage) when a class
      either derives from a class or has a member field of a type that
      was declared in an anonymous namespace.
      It is also opposed (-Werror=attributes) to visibility attributes
      being defined at explicit template instantiations.
      GCC 8.x further has reservations (-Werror=class-memaccess) about
      letting memset/memcpy modify areas within non-POD objects.
      
      Change-Id: Ic5107bb5ee3af6233e3741e3ef78d03a0a84005a
      Reviewed-on: https://chromium-review.googlesource.com/1208306
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56106}
      9ed4b965
  30. 19 Sep, 2018 1 commit
  31. 17 Sep, 2018 1 commit
  32. 30 Aug, 2018 1 commit
  33. 26 Jul, 2018 1 commit
  34. 15 Mar, 2018 1 commit