This is an archive of the discontinued LLVM Phabricator instance.

[SCEVAA] Avoid forming malformed pointer diff expressions
ClosedPublic

Authored by reames on Nov 17 2021, 10:58 AM.

Details

Summary

This solves the same crash as in D104503, but with a different approach.

The test case test_non_dom demonstrates a case where scev-aa crashes today. (If exercised either by -eval-aa or -licm.) The basic problem is that SCEV-AA expects to be able to compute a pointer difference between two SCEVs for any two pair of pointers we do an alias query on. For (valid, but out of scope) reasons, we can end up asking whether expressions in different sub-loops can alias each other. This results in a subtraction expression being formed where neither operand dominates the other.

The approach this patch takes is to leverage the "defining scope" notion we introduced for flag semantics to detect and disallow the formation of the problematic SCEV. This ends up being relatively straight forward on that new infrastructure. This change does hint that we should probably be verifying a similar property for all SCEVs somewhere, but I'll leave that to a follow on change if we decide to take this approach.

Diff Detail

Event Timeline

reames created this revision.Nov 17 2021, 10:58 AM
reames requested review of this revision.Nov 17 2021, 10:58 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 17 2021, 10:58 AM

Do we have some documentation that indicates what we expect alias() to return in the case where instructionCouldExistWitthOperands fails?

Do we have some documentation that indicates what we expect alias() to return in the case where instructionCouldExistWitthOperands fails?

Not quite sure what you're asking. If we have two pointers, the conservative result should always be MayAlias. Is that what you meant?

efriedma accepted this revision.Nov 17 2021, 12:13 PM

LGTM

Do we have some documentation that indicates what we expect alias() to return in the case where instructionCouldExistWitthOperands fails?

I guess this is sort of out of scope; we're making the queries, and they seem to return something vaguely sane.

llvm/test/Analysis/ScalarEvolution/scev-aa.ll
306

"%addr1" here represents the value of the address in the last iteration of the first subloop? Should SCEVAA try to canonicalize the SCEV with getSCEVAtScope() or something like that to get more precise results?

This revision is now accepted and ready to land.Nov 17 2021, 12:13 PM

Do we have some documentation that indicates what we expect alias() to return in the case where instructionCouldExistWitthOperands fails?

Not quite sure what you're asking. If we have two pointers, the conservative result should always be MayAlias. Is that what you meant?

I mean, if we do an alias query with a pair of Instruction* that don't have a common scope, are all AA implementations required to always return MayAlias? Call llvm_unreachable? Or can we perform some sort of approximation of the possible values produced by the Instruction? If we do approximate the value, what are the rules for that?

This revision was landed with ongoing or failed builds.Nov 17 2021, 12:38 PM
This revision was automatically updated to reflect the committed changes.

Do we have some documentation that indicates what we expect alias() to return in the case where instructionCouldExistWitthOperands fails?

Not quite sure what you're asking. If we have two pointers, the conservative result should always be MayAlias. Is that what you meant?

I mean, if we do an alias query with a pair of Instruction* that don't have a common scope, are all AA implementations required to always return MayAlias? Call llvm_unreachable? Or can we perform some sort of approximation of the possible values produced by the Instruction? If we do approximate the value, what are the rules for that?

Ah, this is a question about the alias interface on AliasAnalysis. It doesn't appear to address this question. I'm honestly not sure if we could return anything other than MayAlias, and very deliberately tried not to open that can of worms. :)

llvm/test/Analysis/ScalarEvolution/scev-aa.ll
306

We seem to already get all the alias precision we can on this example. The getSCEVAtScope question is reasonable, but doesn't appear to be needed at least on this one.