[all-commits] [llvm/llvm-project] 835104: [LSR] Drop potentially invalid nowrap flags when s...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 835104a1141a06ae7821fe2b642b9603e00aa17b
      https://github.com/llvm/llvm-project/commit/835104a1141a06ae7821fe2b642b9603e00aa17b
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2021-01-25 (Mon, 25 Jan 2021)

  Changed paths:
    M llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp
    M llvm/test/CodeGen/Thumb2/LowOverheadLoops/fast-fp-loops.ll
    M llvm/test/CodeGen/Thumb2/LowOverheadLoops/mve-float-loops.ll
    M llvm/test/CodeGen/Thumb2/LowOverheadLoops/mve-tail-data-types.ll
    M llvm/test/Transforms/LoopStrengthReduce/X86/pr46943.ll
    M llvm/test/Transforms/LoopStrengthReduce/X86/sibling-loops.ll

  Log Message:
  -----------
  [LSR] Drop potentially invalid nowrap flags when switching to post-inc IV (PR46943)

When LSR converts a branch on the pre-inc IV into a branch on the
post-inc IV, the nowrap flags on the addition may no longer be valid.
Previously, a poison result of the addition might have been ignored,
in which case the program was well defined. After branching on the
post-inc IV, we might be branching on poison, which is undefined behavior.

Fix this by discarding nowrap flags which are not present on the SCEV
expression. Nowrap flags on the SCEV expression are proven by SCEV
to always hold, independently of how the expression will be used.
This is essentially the same fix we applied to IndVars LFTR, which
also performs this kind of pre-inc to post-inc conversion.

I believe a similar problem can also exist for getelementptr inbounds,
but I was not able to come up with a problematic test case. The
inbounds case would have to be addressed in a differently anyway
(as SCEV does not track this property).

Fixes https://bugs.llvm.org/show_bug.cgi?id=46943.

Differential Revision: https://reviews.llvm.org/D95286