llvm dev - Feb 2016 - RFC: Add guard intrinsics to LLVM

On Mon, Feb 22, 2016 at 9:40 PM, Andrew Trick <atrick at apple.com>
wrote:
> I actually see fences as a proxy for potential inter-process
> communication and I/O. It's important that any opaque library call
> could contain a fence.
This makes perfect sense to me now, especially if you want to use
@trap_on for safety checks.  Without re-ordering restrictions, a
failed @trap_on will end up looking a lot like UB (since, say, you
could reorder a failing range check across a call to fflush); and so
that would be bad.  You'd still have to be careful around
inaccessiblememonly and friends, though.

-- Sanjoy

> 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/20160222/ac6a279b/attachment.html>

Assuming everyone is on the same page, here's a rough high level agenda:


# step A: Introduce an `interposable` function attribute

We can bike shed on the name and the exact specification, but the
general idea is that you cannot do IPA / IPO over callsites calling
`interposable` functions without inlining them.  This attribute will
(usually) have to be used on function bodies that can deoptimize (e.g. has a
side exit / guard it in); but also has more general use cases.


# step B: Introduce a `side_exit` intrinsic

Specify an `@llvm.experimental.side_exit` intrinsic, polymorphic on the
return type:

 - Consumes a "deopt" continuation, and replaces the current physical
   stack frame with one or more interpreter frames (implementation
   provided by the runtime).
 - Calls to this intrinsic must be `musttail` (verifier will check this)
 - We'll have some minor logic in the inliner such that when inlining @f
into @g
   in

     define i32 @f() {
       if (X) return side_exit() [ "deopt"(X) ];
       return i32 20;
     }

     define i64 @g() {
       if (Y) {
         r = f() [ "deopt"(Y) ];
         print(r);
     }

   We get

     define i64 @g() {
       if (Y) {
         if (X) return side_exit() [ "deopt"(Y, X) ];
         print(20);
       }
     }

   and not

     define i64 @g() {
       if (Y) {
         r = X ? (side_exit() [ "deopt"(Y, X) ]) : 20;
         print(r);
     }


# step C: Introduce a `guard_on` intrinsic

Will be based around what was discussed / is going to be discussed on
this thread.


(I think Philip was right in suggesting to split out a "step B" that
only introduces a `side_exit` intrinsic.  We *will* have to specify
them, since we'd like to optimize some after we've lowered guards into
explicit control flow, and for that we need a specification of side
exits.)


# aside: non-managed languages and guards

Chandler raised some points on IRC around making `guard_on` (and
possibly `side_exit`?) more generally applicable to unmanaged
languages; so we'd want to be careful to specify these in a way that
allows for implementations in an unmanaged environments (by function
cloning, for instance).

-- Sanjoy

>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>