[llvm-dev] RFC: Add guard intrinsics to LLVM
Vaivaswatha Nagaraj via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 22 22:27:24 PST 2016
>inaccessiblememonly functions, without further constraints, cannot be
reordered w.r.t each other or CSE’d.
>However, readonly + inaccessiblememory attributes could be combined to
allow both of those transformations
Although this seems right, from what I understand, read-only itself should
be sufficient to do these optimizations.
More importantly, inaccessiblememonly was introduced to aid GlobalsAA to be
able to say that a function, even though not marked read-only may not
access a program visible global. Currently the attribute is not made use of
anywhere and there is a plan to remove the attribute in future versions.
Thanks,
- Vaivaswatha
On Tue, Feb 23, 2016 at 11:39 AM, Andrew Trick <atrick at apple.com> wrote:
>
> On Feb 22, 2016, at 9:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
> wrote:
>
> You'd still have to be careful around
> inaccessiblememonly and friends, though.
>
>
> I either missed that attribute or forgot about it. The semantics aren’t
> well specified. I would hope that it works as follows:
> inaccessiblememonly functions, without further constraints, cannot be
> reordered w.r.t each other or CSE’d. However, readonly + inaccessiblememory
> attributes could be combined to allow both of those transformations.
>
> @trap_on could be reordered with readonly + inaccessiblememory.
>
> I’m suggesting that readonly should refer to both accessible (LLVM) and
> inaccessible (system) memory.
>
> -Andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/444b1f04/attachment.html>
More information about the llvm-dev
mailing list