Skip to content
  1. Sep 21, 2021
  2. Sep 20, 2021
    • Nikita Popov's avatar
      [IR] Add helper to convert offset to GEP indices · dd022656
      Nikita Popov authored
      We implement logic to convert a byte offset into a sequence of GEP
      indices for that offset in a number of places. This patch adds a
      DataLayout::getGEPIndicesForOffset() method, which implements the
      core logic. I've updated SROA, ConstantFolding and InstCombine to
      use it, and there's a few more places where it looks relevant.
      
      Differential Revision: https://reviews.llvm.org/D110043
      dd022656
    • David Sherwood's avatar
      [Analysis] Add support for vscale in computeKnownBitsFromOperator · f988f680
      David Sherwood authored
      In ValueTracking.cpp we use a function called
      computeKnownBitsFromOperator to determine the known bits of a value.
      For the vscale intrinsic if the function contains the vscale_range
      attribute we can use the maximum and minimum values of vscale to
      determine some known zero and one bits. This should help to improve
      code quality by allowing certain optimisations to take place.
      
      Tests added here:
      
        Transforms/InstCombine/icmp-vscale.ll
      
      Differential Revision: https://reviews.llvm.org/D109883
      f988f680
  3. Sep 19, 2021
  4. Sep 18, 2021
  5. Sep 17, 2021
  6. Sep 16, 2021
  7. Sep 15, 2021
  8. Sep 14, 2021
  9. Sep 13, 2021
  10. Sep 12, 2021
  11. Sep 11, 2021
  12. Sep 10, 2021
  13. Sep 09, 2021
    • Sanjay Patel's avatar
    • Sanjay Patel's avatar
      [InstCombine] remove a buggy set of zext-icmp transforms · 97a4e7b7
      Sanjay Patel authored
      The motivating case is an infinite loop shown with a reduced test from:
      https://llvm.org/PR51762
      
      To solve this, I'm proposing we delete the most obviously broken part of this code.
      
      The bug example shows a fundamental problem: we ask computeKnownBits if a transform
      will be profitable, alter the code by creating new instructions, then rely on
      computeKnownBits to return the same answer to actually eliminate instructions.
      
      But there's no guarantee that the results will be the same between the 1st and 2nd
      calls. In the infinite loop example, we get different answers, so we add
      instructions that conflict with some other transform, and we're stuck.
      
      There's at least one other problem visible in the test diff for
      `@zext_or_masked_bit_test_uses`: the code doesn't check uses properly, so we can
      end up with extra instructions created.
      
      Last, it's not clear if this set of transforms actually improves analysis or
      codegen. I spot-checked a few targets and don't see a clear win:
      https://godbolt.org/z/x87EWovso
      
      If we do see a regression from this change, codegen seems like the right place to
      add a cmp -> bit-hack fold.
      
      If this is too big of a step, we could limit the computeKnownBits calls by not
      passing a context instruction and/or limiting the recursion. I checked that those
      would stop the infinite loop for PR51762, but that won't guarantee that some other
      example does not fall into the same loop.
      
      Differential Revision: https://reviews.llvm.org/D109440
      97a4e7b7
  14. Sep 08, 2021
  15. Sep 07, 2021
Loading