This is an archive of the discontinued LLVM Phabricator instance.

[x86] try to use PCMPGT instead of not-of-PCMPEQ
ClosedPublic

Authored by spatel on May 11 2021, 1:15 PM.

Details

Summary

This is motivated by the example in https://llvm.org/PR50055 , but it doesn't do anything for that bug currently because we don't actually have a zero-extended setcc there. We'll need to do something else to see through to the ideal compare code on that one.

Proof for the generic transform (inverse of what we would try to do in combining):
https://alive2.llvm.org/ce/z/aBL-Mg

Diff Detail

Event Timeline

spatel created this revision.May 11 2021, 1:15 PM
spatel requested review of this revision.May 11 2021, 1:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 11 2021, 1:15 PM

Seems reasonable to me.

llvm/lib/Target/X86/X86ISelLowering.cpp
23082–23084

I think this could be a bit more readable if it specified the u/s of the comparison predicates.

spatel updated this revision to Diff 344560.May 11 2021, 2:16 PM
spatel marked an inline comment as done.

Patch updated:
Make the code comment clearer by specifying signed comparison.

This revision is now accepted and ready to land.May 11 2021, 2:29 PM
RKSimon accepted this revision.May 12 2021, 1:28 AM

LGTM cheers

Is the inverse (known negative) case worth it do you think?

----------------------------------------
define i1 @src(i32 %x) {
%0:
  %ispos = icmp slt i32 %x, 0
  assume i1 %ispos
  %icmp = icmp ne i32 %x, 0
  ret i1 %icmp
}
=>
define i1 @tgt(i32 %x) {
%0:
  %icmp = icmp sgt i32 0, %x
  ret i1 %icmp
}
Transformation seems to be correct!

Is the inverse (known negative) case worth it do you think?

Yes - I didn't draft that one yet to see if existing tests will show it, but we probably want that for symmetry. I'll look at that next.

This revision was landed with ongoing or failed builds.May 12 2021, 5:25 AM
This revision was automatically updated to reflect the committed changes.

Is the inverse (known negative) case worth it do you think?

Yes - I didn't draft that one yet to see if existing tests will show it, but we probably want that for symmetry. I'll look at that next.

I don't see a known-bits way to capture it. We need a isKnownNotPositive (if any non-sign-bit is set, then sign-bit is also set).
The Alive2 example you showed is correct because the result is always true. We want this instead:
https://alive2.llvm.org/ce/z/v7jxhL