[PATCH] D20206: GlobalsAA: Don't assume that intrinsics can't access global variables

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Thu May 12 09:34:15 PDT 2016


On Thu, May 12, 2016 at 8:46 AM, Tom Stellard <thomas.stellard at amd.com>
wrote:

> tstellarAMD added a comment.
>
> In http://reviews.llvm.org/D20206#428381, @dberlin wrote:
>
> > So this is an interesting question.
> >  Outside of very specific intrinsics (barriers), or intrinsics passed
> global
> >  variables, which intrinsics do you believe can affect global variables
> and
> >  why?
>
>
> There probably aren't many besides barriers and maybe some of the cache
> flushing intrinsics.
>
> > :)
>
> >
>
> > (Because if the answer is "none", we should probably make the ability to
>
> >  read/write non-passed-in globals an intrinsic property that folks have
> to
>
> >  opt-in to)
>
>
> My thinking is that is would be easier to treat intrinsics and functions
> the same rather than having to add an attribute that makes intrinsics
> behave like functions.


Yes, sorry, didn't realize we could already use attributes on intrinsics,
because i didn't look closely enough.
This sounds like the right plan.

There are already attributes like: readnone, readonly, argmemonly that can
> be used to specify that an intrinsic won't access globals.  It doesn't seem
> like it is too much trouble to ask people to use those for intrinsics, and
> it looks like most intrinsics already are using these.
>

Yes, though i don't think GlobalsModRef is using argmemonly like it should,
or at least, i don't see it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160512/6a1a591c/attachment.html>


More information about the llvm-commits mailing list