This is an archive of the discontinued LLVM Phabricator instance.

[BasicAA] Teach BasicAA to handle the inaccessiblememonly and inaccessiblemem_or_argmemonly attributes
ClosedPublic

Authored by andrew.w.kaylor on Nov 7 2016, 6:12 PM.

Details

Summary

This patch adds support for the inaccessiblememonly and inaccessiblemem_or_argmemonly attributes to the BasicAA.

I am assuming that any function which is not marked as not referencing memory may be accessing "inaccessible" memory. There doesn't seem to be a way for a function to indicate otherwise, so we must make this conservative assumption.

I am also assuming that functions marked as "readonly" may read but will not write to inaccessible memory (and similarly with "writeonly"). This feels somewhat awkward to me, since the readonly attribute is fairly specific and probably does rule out inaccessible memory access but again, lacking a way to indicate that inaccessible memory is not referenced, I think this is the assumption we need to make.

It is my understanding that the inaccessible memory attributes were originally added to aid with JIT optimization, but I intend to use them very soon with the constrained floating point intrinsics to model access to the FP environment.

Diff Detail

Repository
rL LLVM

Event Timeline

andrew.w.kaylor retitled this revision from to [BasicAA] Teach BasicAA to handle the inaccessiblememonly and inaccessiblemem_or_argmemonly attributes.
andrew.w.kaylor updated this object.
andrew.w.kaylor set the repository for this revision to rL LLVM.
andrew.w.kaylor added a subscriber: llvm-commits.
hfinkel accepted this revision.Nov 8 2016, 11:08 AM
hfinkel edited edge metadata.

This LGTM. We should use this for @llvm.assume, etc.

but I intend to use them very soon with the constrained floating point intrinsics to model access to the FP environment.

This will work, but we might want a separate tracking state for this (because otherwise we won't be able to infer readonly for any functions with FP operations, which is going to be very unfortunate). We might do this as a later enhancement, however.

This revision is now accepted and ready to land.Nov 8 2016, 11:08 AM
This revision was automatically updated to reflect the committed changes.

This will work, but we might want a separate tracking state for this (because otherwise we won't be able to infer readonly for any functions with FP operations, which is going to be very unfortunate). We might do this as a later enhancement, however.

I was also thinking that a dedicated attribute for FP environment access would be nice, but I agree that we could add that later, after the rest of this is working.

I thought about the problems with inferring function attributes, and I think the scope of the problem will be fairly limited since we only really care about the FP environment access in cases where we are using the new intrinsics (yet to be introduced) to get non-default behavior. Even though every FP operation does implicitly access the FP environment, the cases where we actually want to model that should be fairly limited and decreased optimization possibilities is an expected outcome.

I have a long term plan to go back and try to restore as many optimizations opportunities as possible for the constrained FP cases, but in the short term I just want to get it working correctly without causing any havoc in the default case.