[PATCH] D148414: [InstCombine] Expand `foldSelectICmpAndOr` -> `foldSelectICmpAndBinOp` to work for any binop

Noah Goldstein via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Apr 23 10:38:02 PDT 2023


goldstein.w.n added a comment.

In D148414#4290296 <https://reviews.llvm.org/D148414#4290296>, @nikic wrote:

> Why is this legal for all binops? Doesn't this transform require that the neutral element of the binop is zero? So it would work for or, xor or add, but not for mul or and for example?

Yeah you are right. Not sure what I was thinking...

> I think this entire transform should probably be handled as a two step process: First, `Cond ? X : BinOp(X, C)` should become `BinOp(X, Cond ? NeutralC : C)` and then this fold should work on `Cond ? 0 : C` as the root.
> We actually already do the former canonicalization, but not in the case where `C` is constant.

Where do we do the canonicalization?

> This will cleanly separate out the actual binop handling. Only disadvantage is that we won't be able to handle the case where the binop has multiple uses anymore, but that's a general issue with composable folds that we can ignore unless there is reason to believe that multi-use is motivating for the current handling.

Why won't we be able to handle multi-use anymore? If we do it like this, seems this function can be deleted once we get the canonicalization of `Cond ? X : BinOp(X, C)` -> `BinOp(X, Cond ? NeutralC : C)`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148414



More information about the llvm-commits mailing list