This is an archive of the discontinued LLVM Phabricator instance.

[FunctionAttrs] Infer precise FMRB
ClosedPublic

Authored by nikic on Sep 23 2022, 5:51 AM.

Details

Summary

This updates checkFunctionMemoryAccess() to infer a precise FunctionModRefBehavior, rather than an approximation split into read/write and argmemonly.

Afterwards, we still map this back to imprecise function attributes. This still allows us to infer some cases that we previously did not handle, namely inaccessiblememonly and inaccessiblemem_or_argmemonly. In practice, this means we get better memory attributes in the presence of intrinsics like @llvm.assume.

Diff Detail

Event Timeline

nikic created this revision.Sep 23 2022, 5:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 23 2022, 5:51 AM
nikic requested review of this revision.Sep 23 2022, 5:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 23 2022, 5:51 AM
reames accepted this revision.Sep 26 2022, 8:45 AM

LGTM w/suggestion.

llvm/lib/Transforms/IPO/FunctionAttrs.cpp
216

The claim that no instruction other than a call can access inaccessiblememory seems reasonable on the surface, but is a somewhat significant change. The corner cases would be something like maybe an indirect br.

If possible, could you separate this into it's own commit for risk reduction? Having something easy to revert could be helpful.

This revision is now accepted and ready to land.Sep 26 2022, 8:45 AM
nikic added inline comments.Sep 26 2022, 9:51 AM
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
216

Interesting point. Thinking about this again, I think there are two cases here:

  1. If we have a MemoryLocation, then only that location can be accessed and an IR location can't be inaccessible by definition.
  1. If we don't have a MemoryLocation (but still access memory), then things are less clear cut. Checking the implementation, the (non-call) instructions for which this happens are fence, catchpad and catchret.

In the interest of being conservative, it probably makes sense to keep the inaccessiblemem access in the latter case. I'm not familiar enough with the semantics of these instructions to exclude this -- e.g. could a fence synchronize atomic operations on an inaccessible object?

This revision was automatically updated to reflect the committed changes.

This change introduced a problem, or exposed an already existing bug.
Here you can find a reproducer: https://reviews.llvm.org/P8291
Could we get this change reverted until you a working on a fix?