Sanjoy Das via llvm-dev
2016-Feb-23 05:58 UTC
[llvm-dev] 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
Andrew Trick via llvm-dev
2016-Feb-23 06:09 UTC
[llvm-dev] RFC: Add guard intrinsics to LLVM
> 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>
Sanjoy Das via llvm-dev
2016-Feb-23 06:26 UTC
[llvm-dev] RFC: Add guard intrinsics to LLVM
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
Vaivaswatha Nagaraj via llvm-dev
2016-Feb-23 06:27 UTC
[llvm-dev] RFC: Add guard intrinsics to LLVM
>inaccessiblememonly functions, without further constraints, cannot bereordered w.r.t each other or CSE’d.>However, readonly + inaccessiblememory attributes could be combined toallow 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>