[all-commits] [llvm/llvm-project] 5cb568: [GuardWidening] Choose right point for generating ...

[Max Kazantsev via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5cb568a37a53a9b0fd8fc9c2c35870cad43623e9
      https://github.com/llvm/llvm-project/commit/5cb568a37a53a9b0fd8fc9c2c35870cad43623e9
  Author: Max Kazantsev <mkazantsev at azul.com>
  Date:   2023-01-31 (Tue, 31 Jan 2023)

  Changed paths:
    M llvm/lib/Transforms/Scalar/GuardWidening.cpp
    M llvm/test/Transforms/GuardWidening/basic_widenable_condition_guards.ll
    M llvm/test/Transforms/GuardWidening/loop_invariant_widenable_condition.ll
    M llvm/test/Transforms/GuardWidening/mixed_guards.ll
    M llvm/test/Transforms/GuardWidening/pr60234.ll

  Log Message:
  -----------
  [GuardWidening] Choose right point for generating wide condition for branches. PR60234

When guards are represented as widenable branches, there is a tricky
situation when the branch stays in loop but widenable condition doesn't.
It means that the widenable condition is loop-invariant, and some other
optimizations could have done changes using this fact.

If widening is allowed to create widened condition inside this loop,
and join the loop-invariant wc with some non-invariant facts, it can
cause miscompile. See example of this at https://github.com/llvm/llvm-project/issues/60234.

The solution is to adjust the point of generationg the wide condition,
and therefore of hoisting all related parts there. It should not be before
the branch, but before the widenable_condition call. The fact that `wc()`
and the wide condition are in the same block guarantees that they will
not violate the invariance property for any loop.

Differential Revision: https://reviews.llvm.org/D142693
Reviewed By: apilipenko