[all-commits] [llvm/llvm-project] 36b932: [NARY] Don't optimize min/max if there are side uses

[ebrevnov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 36b932d6a385bb97efe17818a7a47d29d2d8acf3
      https://github.com/llvm/llvm-project/commit/36b932d6a385bb97efe17818a7a47d29d2d8acf3
  Author: Evgeniy Brevnov <ybrevnov at azul.com>
  Date:   2021-04-12 (Mon, 12 Apr 2021)

  Changed paths:
    M llvm/lib/Transforms/Scalar/NaryReassociate.cpp
    A llvm/test/Transforms/NaryReassociate/nary-req.ll

  Log Message:
  -----------
  [NARY] Don't optimize min/max if there are side uses

Say we have
%1=min(%a,%b)
%2=min(%b,%c)
%3=min(%2,%a)

The optimization will try to reassociate the later one so that we can rewrite it to %3=min(%1, %c) and remove %2.
But if %2 has another uses outside of %3 then we can't remove %2 and end up with:

%1=min(%a,%b)
%2=min(%b,%c)
%3=min(%1, %c)

This doesn't harm by itself except it is not profitable and changes IR for no good reason.
What is bad it triggers next iteration which finds out that optimization is applicable to %2 and %3 and generates:

%1=min(%a,%b)
%2=min(%b,%c)
%3=min(%1,%c)
%4=min(%2,%a)

and so on...

The solution is to prevent optimization in the first place if intermediate result (%2) has side uses and
known to be not removed.

Reviewed By: mkazantsev

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