[PATCH] D125248: [instcombine] Propagate freeze back to def

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

In D125248#3501917 <https://reviews.llvm.org/D125248#3501917>, @mtrofin wrote:

> In D125248#3501446 <https://reviews.llvm.org/D125248#3501446>, @nikic wrote:
>
>> I don't think this is the right place to do this. You should either:
>>
>> 1. Remove the one-use restriction on this fold, and replace other uses with the frozen variant as well. This is on the premise that pushing freeze higher is more worthwhile than having some un-frozen uses.
>>
>> 2. Adjust the freezeDominatedUses() fold to freeze not only dominated uses. Basically canonicalize %x to freeze %x. This is on the premise that allowing more exploitation of value identity is more worthwhile than having un-frozen uses.
>
> I think in either case the `freeze %s` def needs to dominate its uses.

Sure -- to be clear, the suggestion for the second approach is to move the freeze up so that it does dominate all uses and allows all of them to be replaced. This is basically what you're doing here, with the crucial difference that it happens for all freeze instructions, not just the ones produced by this particular transform.

There is a tradeoff here between leaving some uses to not use freeze (and possibly allowing additional optimizations for them, as freeze is usually an optimization-blocker) and allowing folds based on value-identity (which benefit from all uses being freeze(%x), not %x).

With that in mind, I would probably lean toward dropping the one-use check on this fold as a starting point -- it's more conservative, but should still cover your motivating case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125248