This is an archive of the discontinued LLVM Phabricator instance.

[AA] Consider globalmemonly in getModRefInfo()
Needs RevisionPublic

Authored by MugilanGN on Sep 11 2021, 11:36 AM.

Details

Reviewers
jdoerfert
nikic
Summary

If a function is GlobalMemOnly and a memory location does not point to a global object, getModRefInfo can infer that no aliasing between the function and the location can occur.

Diff Detail

Event Timeline

MugilanGN created this revision.Sep 11 2021, 11:36 AM
MugilanGN requested review of this revision.Sep 11 2021, 11:36 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 11 2021, 11:36 AM
nikic requested changes to this revision.Sep 11 2021, 11:58 AM
nikic added a subscriber: nikic.
nikic added inline comments.
llvm/lib/Analysis/AliasAnalysis.cpp
283

Just because the underlying object is not a global value, doesn't mean that it can't be based on one -- e.g. imagine a global being passed to a function argument. getUnderlyingObject() will just give you the argument in that case, which may still alias with a global.

At the very least, you need to check for isIdentifiedObject() here. However, even that may be insufficient, as noalias arguments are identified objects, but I don't think you can apply this optimization to them (a noalias argument could point to a global, and a globalmemonly function could access the global through a passed-on noalias argument).

This revision now requires changes to proceed.Sep 11 2021, 11:58 AM
jdoerfert added inline comments.Sep 11 2021, 3:12 PM
llvm/lib/Analysis/AliasAnalysis.cpp
283

The last part is were it becomes interesting. If we say accesses to a global via an argument are globalmemonly or argmemonly. I think, given argmemonly, we could/should not say a function accessing globals only but via argument pointers can be globalmemonly. That resolves the problem here, I think. Identified objects are necessary for sure though.