This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Add freezeAllUsesOfArgument to visitFreeze
ClosedPublic

Authored by hyeongyukim on Jul 18 2021, 5:11 AM.

Details

Summary

In D106041, a freeze was added before the branch condition to solve the miscompilation problem of SimpleLoopUnswitch.
However, I found that the added freeze disturbed other optimizations in the following situations.

arg.fr = freeze(arg)
use(arg.fr)
...
use(arg)

It is a problem that occurred when arg and arg.fr were recognized as different values.
Therefore, changing to use arg.fr instead of arg throughout the function eliminates the above problem.
Thus, I add a function that changes all uses of arg to freeze(arg) to visitFreeze of InstCombine.

Diff Detail

Event Timeline

hyeongyukim created this revision.Jul 18 2021, 5:11 AM
hyeongyukim requested review of this revision.Jul 18 2021, 5:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 18 2021, 5:11 AM

update vector-reductions-logical.ll

lebedev.ri added inline comments.
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
3612

Why not just FI.getFunction()->getEntryBlock()->getFirstInsertionPt()?

https://alive2.llvm.org/ce/z/WKSW66
https://alive2.llvm.org/ce/z/vqiQLT

The correctness of the test code can be found in the link above.

I'm not really sure why we are okay with doing this specifically when we are freezing the function argument, but not any other value?

tambre added a subscriber: tambre.Jul 18 2021, 7:18 AM

I think the right way to go about this would be, for any F = freeze V replace all uses of V dominated by F with F. Replacing other uses of V by hoisting the freeze is likely not profitable.

freeze only dominated uses rather than all uses.

hyeongyukim added inline comments.Jul 19 2021, 4:07 AM
llvm/test/Transforms/InstCombine/freeze.ll
46

If it returns x instead of -1, there is no problem with correctness.
But does this cause performance degradation?

aqjune added inline comments.Jul 19 2021, 4:09 AM
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
3609

If FI's operand is constant (e.g., undef), getting dominance relation might not work well.

hyeongyukim marked an inline comment as done.Jul 19 2021, 4:12 AM
hyeongyukim added inline comments.
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
3609

Is there any other consideration(except constant) when obtaining the dominance relation?

aqjune added inline comments.Jul 19 2021, 4:12 AM
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
3609

Casting to Instruction will work well.

Modified to returns false if Op is constant

nikic added inline comments.Jul 19 2021, 11:50 AM
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
3609

Casting to Value makes no sense, it's already a Value. (Okay, it's a Use, but it decays to Value.)

3614

Maybe use replaceUsesWithIf()?

3617

You should be checking domination on Use, not the user. For example, a use in a phi might be dominated even though the phi is not dominated.

3632

I think you should do this after the other optimizations.

Note that Transforms/PhaseOrdering/X86::vector-reductions-logical.ll needs an update.

Modify to use replaceUsWithIf, update Transforms/PhaseOrdering/X86::vector-reductions-logical.ll

nikic added a comment.Jul 20 2021, 1:00 PM

Looks okay, just some nits.

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
3609

This comment still holds. In fact all three dyn_casts in this function are unnecessary.

llvm/test/Transforms/InstCombine/freeze.ll
140

Comment is outdated.

189

I think it would be good to add the special case of there being a second freeze of the same value, as we see in the adjusted PhaseOrdering tests. In that case we effectively end up CSEing the freezes as a side-effect of this transform.

Add test case, remove useless dyn_casts

The patch looks good to me.
@hyeongyukim said that this patch also resolves the regression in scalar evolution's analyses that is mentioned in https://llvm.org/pr51043 's comment 13, which is good news.

nikic accepted this revision.Jul 23 2021, 10:14 AM

LGTM

This revision is now accepted and ready to land.Jul 23 2021, 10:14 AM
This revision was landed with ongoing or failed builds.Jul 24 2021, 2:09 AM
This revision was automatically updated to reflect the committed changes.