This is an archive of the discontinued LLVM Phabricator instance.

[BasicAA] Migrate "same base pointer" logic to decomposed GEPs
ClosedPublic

Authored by nikic on Dec 5 2020, 12:39 PM.

Details

Summary

BasicAA has some special bit of logic for "same base pointer" GEPs that performs a structural comparison: It only looks at two GEPs with the same base (as opposed to two GEP chains with a MustAlias base) and compares their indexes in a limited way. I generalized part of this code in D91027, and this patch merges the remainder into the normal decomposed GEP logic.

What this code ultimately wants to do is to determine that gep %base, %idx1 and gep %base, %idx2 don't alias if %idx1 != %idx2, and the access size fits within the stride.

We can express this in terms of a decomposed GEP expression with two indexes scale*%idx1 + -scale*%idx2 where %idx1 != %idx2, and some appropriate checks for sizes and offsets.

This makes the reasoning slightly more powerful, and more importantly brings all the GEP logic under a common umbrella.

Diff Detail

Event Timeline

nikic created this revision.Dec 5 2020, 12:39 PM
nikic requested review of this revision.Dec 5 2020, 12:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 5 2020, 12:39 PM
nikic added inline comments.Dec 5 2020, 12:41 PM
llvm/test/Analysis/BasicAA/fallback-mayalias.ll
6

This test started returning NoAlias after this patch. This is correct, but the point of this test is to check for a case that is actually NoAlias, but in a way that BasicAA does not recognize, so I picked out a different case.

reames requested changes to this revision.Dec 5 2020, 2:48 PM

Ok, you and I are clearly thinking about the same problems. :) I have a patch which I hadn't yet posted to handle this exact same case. I just needed to get prerequisites out of the way in terms of D92698 and D92694. I'm happy to defer to you and act as knowledgeable reviewer though!

llvm/lib/Analysis/BasicAliasAnalysis.cpp
1286

You're missing the bug fix for the reasoning under recursive phis that I just landed.in bfda6941. Please add the appropriate VisitedPhiBBs.empty check to your conditions.

1289

You're missing a necessary check here. You need to ensure that scale > size and scale mod size == 0. Otherwise, you can have a case such as scale == 2, size == 8, and have the (unaligned) accesses alias even if the indices differ.

1292

I'm not following your logic here, and I think you may have it backwards.

If we know that the offsets are equal, scales are equal, and indices aren't, then we have no alias. If we have different offsets, then we need to reason about the offset access sequences. You might be trying to handle the offset pattern case, but if so, I'm not following?

This revision now requires changes to proceed.Dec 5 2020, 2:48 PM
nikic added inline comments.Dec 5 2020, 3:06 PM
llvm/lib/Analysis/BasicAliasAnalysis.cpp
1286

The check for that is in the line directly below this one :)

1289

This is handled by the offset checks below, or at least supposed to. For simplicity, let's assume that DecompGEP1.Offset is zero, so OffsetLo/Hi below are just +/-Scale.

// Possibility 1, access starts at +Scale or higher
[0...V2Size) ... [Scale, Scale+V1Size]
// Possibility 2, access starts at -Scale or lower
[-Scale, -Scale+V1Size) ... [0...V2Size)

This checks that the sizes are smaller than the scale. I don't believe that scale mod size == 0 is a requirement. If we have a scale of 4 it shouldn't matter whether our access size is 2 or 3, unless I'm missing something.

The conditions used here are analogous to the ones a bit higher up (the AllNonNegative/AllNonPositive ones).

1292

Does my previous comment make this clearer? Something to keep in mind here is that the second access is always at zero. What the non-equality gives us is that the first access doesn't start in the range (-Scale, Scale). With the offset, it doesn't start in the range (-Scale+Offset, Scale+Offset).

reames accepted this revision.Dec 5 2020, 4:33 PM

LGTM. I had to grab a sheet of paper and run some examples to convince myself that your code worked - even with the explanation - but I got there eventually. :)

This covers quite a bit more than the original code, and (now that 8f076291 has landed) entirely subsumes my local patch. Nice!

This revision is now accepted and ready to land.Dec 5 2020, 4:33 PM
This revision was landed with ongoing or failed builds.Dec 6 2020, 1:31 AM
This revision was automatically updated to reflect the committed changes.