<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">You're proposing a unified intrinsic that allows Philip's call target reasoning and the current "anything goes" semantics.  I strongly dislike unifying the two.  I don't believe that the current semantics are cleanly expressible using Philip's intrinsic.  Specifying patchpoint semantics in a way that implies that the call target is always called breaks inline caches.  Even if you could make those things work, you'd still have to solve other issues, like the types used to pass the call target.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">How would a unified intrinsic work for dynamic object access inline caches and virtual call inline caches?  Presumably you'd want to have a special fake call target that means "this can do anything".  You could say that null means "anything" but this feels ugly.  Other than that, my understanding is that LLVM IR currently doesn't allow for any other kind of "this is a call target that is guaranteed to not be analyzable" construct - hypothetically any extern call could be resolved with LTO or something else.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Claiming in the documentation that the point of a patchpoint is that it always calls the call target would be confusing to anyone wanting to implement inline caches using LLVM.  The purpose of inline caches is to change the call target, or to eliminate the call altogether, using post-compilation patch-up.  The semantics of patchpoints should be crystal-clear regarding this aspect of the intrinsic and the fact that this is allowed.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Also, would you expect LLVM phases that perform optimizations using the call target to recover the call target by unwrapping the function-pointer-to-i8* bitcast?  This part is particularly yucky to me.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">There's also the question of how not to break WebKit.  Note that you can accomplish this by saying that a null call target means that the call target can do anything, as I mention above - but I don't like this because it seems like you're creating two intrinsics and selecting them by passing null as one of the arguments rather than selecting them by name.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Long story short: creating unified intrinsics is useful if it clarifies reasoning.  In this case a single unified intrinsic doesn't clarify anything.  We're talking about two different semantics - one that means call and another that means "clobber the world" - and so we should keep them separate.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <div id="bloop_sign_1399057275295571200" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-Phil</div><div style="font-family:helvetica,arial;font-size:13px"><br></div></div> <br><p style="color:#000;">On May 2, 2014 at 12:00:40 PM, Eric Christopher (<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>On Fri, May 2, 2014 at 11:58 AM, Philip Reames

<br><listmail@philipreames.com> wrote:

<br>>

<br>> On 05/02/2014 11:57 AM, Filip Pizlo wrote:

<br>>

<br>>

<br>> On May 2, 2014 at 11:53:25 AM, Eric Christopher (echristo@gmail.com) wrote:

<br>>

<br>> On Wed, Apr 30, 2014 at 10:34 PM, Philip Reames

<br>> <listmail@philipreames.com> wrote:

<br>>> Andy - If you're not already following this closely, please start. We've

>> gotten into fairly fundamental questions of what a patchpoint does.

<br>>>

<br>>> Filip,

<br>>>

<br>>> I think you've hit the nail on the head. What I'm thinking of as being

<br>>> patchpoints are not what you think they are. Part of that is that I've got

<br>>> a local change which adds a very similar construction (called

<br>>> "statepoints"

<br>>> for the moment), but I was trying to keep that separate. That also

<br>>> includes

<br>>> a lot of GC semantics which are not under discussion currently. My

<br>>> apologies if that experience bled over into this conversation and made

>> things more confusing.

<br>>>

<br>>> I will note that the documentation for patchpoint say explicitly the

<br>>> following:

<br>>> "The ‘llvm.experimental.patchpoint.*‘ intrinsics creates a function call

<br>>> to

<br>>> the specified <target> and records the location of specified values in the

<br>>> stack map."

<br>>>

<br>>> My reading has always been that a patchpoint *that isn't patched* is

<br>>> simply

<br>>> a call with a stackmap associated with it. To my reading, this can (and

>> did, and does) indicate my proposed usage would be legal.

<br>>>

<br>>

<br>> I like the idea that the target can be assumed to be called. It makes

<br>> optimization of the call possible, etc. I think it's definitely worth

> exploring before we lock down the patchpoint intrinsic.

<br>>

> I will actively oppose this.

<br>>

<br>> I think it sounds like we need to split patchpoint into two cases.  I'm

> going to send a rough proposal for this later today.

<br>>

<br>

<br>A proposal definitely sounds interesting but if it makes more sense to

<br>keep it as single intrinsics then that's preferable. We've already got

two in a kind of weird way with patchpoint and stackmap.

<br>

<br>-eric

<br>

<br><br></div></div></span></blockquote></body></html>