[PATCH] D100211: [InstCombine] Fold cmpeq/ne(and(~X,Y),0) --> cmpeq/ne(or(freeze(X),Y),freeze(X)) (PR44136)

[Juneyoung Lee via Phabricator via llvm-commits]

aqjune added a comment.

If `freeze` is ignored, this canonicalization helps optimizations like GVN to treat `cmpeq (and(~X,Y),0) ` and `cmpeq (or(X,Y),X)` as equivalent ones, right?

If we're going to use `freeze` here, let's leave a comment saying e.g. `TODO: if undef is removed, freeze is not needed`: https://alive2.llvm.org/ce/z/V2Z4Lz
This will help finding out introduction of redundant freezes after undef is removed.

Regarding when to use `freeze`, I don't have a very good policy TBH. But, I agree that we cannot infinitely postpone usage of `freeze`.
There has been progress in SimplifyCFG and JumpThreading to successfully deal with frozen branch conditions.
If InstCombine is also updated to deal with `freeze`, it will be great.
A question is what kind of rules should we introduce first. It depends on which bug to fix; e.g. if we fix some fcmp bug using freeze, we'll need to update fp related optimizations to recognize freeze.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100211/new/

https://reviews.llvm.org/D100211