This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] allow more narrowing of casted select
ClosedPublic

Authored by spatel on Jan 14 2020, 1:14 PM.

Details

Summary

D47163 created a rule that we should not change the casted type of a select when we have matching types in its compare condition. That was intended to help vector codegen, but it also could create situations where we miss subsequent folds as shown in PR44545:
https://bugs.llvm.org/show_bug.cgi?id=44545

By using shouldChangeType(), we can continue to get the vector folds (because we always return false for vector types). But we also solve the motivating bug because it's ok to narrow the scalar select in that example.

Our canonicalization rules around select are a mess, but AFAICT, this will not induce any infinite looping from the reverse transform (but we'll need to watch for that possibility if committed).

Side note: there's a similar use of shouldChangeType() for phi ops just below this diff, and the source and destination types appear to be reversed.

Diff Detail

Event Timeline

spatel created this revision.Jan 14 2020, 1:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 14 2020, 1:14 PM

I'm not sure what kind of fallout this will cause.
For example, won't this affect 'saturating math' peephole?
Won't this affect clamp (min-max) pattern?

spatel added a comment.EditedJan 14 2020, 2:55 PM

I'm not sure what kind of fallout this will cause.
For example, won't this affect 'saturating math' peephole?
Won't this affect clamp (min-max) pattern?

As with PR44545, it's hard to see the fallout in advance, but keep in mind this patch is only restoring part of the behavior before D47163.
If we are detecting min/max patterns with ValueTracking's matchSelectPattern(), that can optionally include casts, so we should be able to peek through. If you have a pattern in mind that would be affected, let me know.

bjope added a comment.Jan 15 2020, 9:44 AM

Thanks for looking into this. I did not know about shouldChangeType but that seems like a useful function here.

Slightly worried just like @lebedev.ri that we might swing back into getting a regression for some other code pattern. But it seems like it at least doesn't hit any regressions for existing lit-tests, so it doesn't regress anything that we have optimized (and added tests for) earlier at least.

Btw, D47163 landed 1.5 years ago, so we have had the regression from PR44545 for awhile. So even if it would be nice to fix it right away, probably no need to rush into something that we do not strongly believe in.

Anyway, the patch LGTM. But let's see if @lebedev.ri has any examples showing that this might a bad idea.

Ping @lebedev.ri - any examples that we can try to fix in advance?

Ping @lebedev.ri - any examples that we can try to fix in advance?

I don't have anything specific actionable in mind right now, feel free to proceed.

spatel accepted this revision.Jan 27 2020, 1:34 PM

(marking as accepted here in Phab based on earlier LGTM)

This revision is now accepted and ready to land.Jan 27 2020, 1:34 PM
This revision was automatically updated to reflect the committed changes.