This is an archive of the discontinued LLVM Phabricator instance.

Add recursive decomposition reasoning to isKnownNonEqual
ClosedPublic

Authored by reames on Dec 4 2020, 3:10 PM.

Details

Summary

The basic idea is that by looking through operand instructions which don't change the equality result that we can push the existing known bits comparison down past instructions which would obscure them.

We have analogous handling in InstSimplify for most - though weirdly not all - of these cases starting from an icmp root. It's a bit unfortunate to duplicate logic, but since my actual goal is to extend BasicAA, the icmp logic doesn't help. (And just makes it hard to test here.)

Note that this can't land until after D92694 as the increase in scope makes that bug much more common.

Diff Detail

Event Timeline

reames created this revision.Dec 4 2020, 3:10 PM
reames requested review of this revision.Dec 4 2020, 3:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 4 2020, 3:10 PM
reames updated this revision to Diff 309679.Dec 4 2020, 3:21 PM

Rebase over landed tests

nikic added a comment.Dec 5 2020, 2:59 AM

We have analogous handling in InstSimplify for most - though weirdly not all - of these cases starting from an icmp root. It's a bit unfortunate to duplicate logic, but since my actual goal is to extend BasicAA, the icmp logic doesn't help. (And just makes it hard to test here.)

Could you add some tests for the BasicAA use case? If that's the intended target, I'm not sure this is the right approach. Currently the BasicAA logic for the non-equal index case is structural, while it should really be based on the index difference of decomposed GEP expressions. I suspect that handling it that way may also handle your motivating case, as e.g. common add operands would get stripped by that.

llvm/lib/Analysis/ValueTracking.cpp
2536

IntToPtr/PtrToInt can truncate, you need to check bit widths here.

nikic added a comment.Dec 5 2020, 8:43 AM

We have analogous handling in InstSimplify for most - though weirdly not all - of these cases starting from an icmp root. It's a bit unfortunate to duplicate logic, but since my actual goal is to extend BasicAA, the icmp logic doesn't help. (And just makes it hard to test here.)

Could you add some tests for the BasicAA use case? If that's the intended target, I'm not sure this is the right approach. Currently the BasicAA logic for the non-equal index case is structural, while it should really be based on the index difference of decomposed GEP expressions. I suspect that handling it that way may also handle your motivating case, as e.g. common add operands would get stripped by that.

After double checking that, it looks like our GEP expression decomposition wouldn't be aggressive enough for that. We only decompose adds if they have one constant operand.

reames added a comment.Dec 5 2020, 2:22 PM

Could you add some tests for the BasicAA use case?

Tests for the basic aa extension will be in the patch for basicaa. I could probably contrive a test case through the existing basic aa use of isKnownNonEqual, but it would take some thought. Are you okay with me landing this as is, and then including supplemental tests in the next patch?

reames updated this revision to Diff 309751.Dec 5 2020, 2:24 PM

Remove ptrtoint and inttoptr due to truncation issue pointed out in review. These can be handled in a follow up patch if needed, my motivating case doesn't require them.

nikic accepted this revision.Dec 5 2020, 2:53 PM

Tests for the basic aa extension will be in the patch for basicaa. I could probably contrive a test case through the existing basic aa use of isKnownNonEqual, but it would take some thought. Are you okay with me landing this as is, and then including supplemental tests in the next patch?

Sure, that's fine. I thought this patch is all there is to it, wasn't aware it requires further changes in BasicAA.

The logic here is pretty straightforward and I don't expect it to be expensive, so LGTM.

llvm/lib/Analysis/ValueTracking.cpp
2502

Should be just Depth here to stay consistent with the computeKnownBits case, and the previous behavior?

This revision is now accepted and ready to land.Dec 5 2020, 2:53 PM
reames added inline comments.Dec 5 2020, 3:56 PM
llvm/lib/Analysis/ValueTracking.cpp
2502

I don't think so. We are recursing into an operand.

This revision was automatically updated to reflect the committed changes.