llvm dev - Apr 2016 - RFC: New function attribute "patchable-prologue"="<kind>"

Hi Eric,

Eric Christopher wrote:
 > Two things:
 >
 > a) I'm not against this

Great!

 > b) So, what's your use case? I've got something I'm idly
working on with
 > someone else where we want patchable targets in both prologue and
 > epilogue (and some other places...), and am thinking of how to make this
 > someone generic enough to build off of there.

We plan to use this to be able to divert control flow from an LLVM
compiled function to "somewhere else" where the "somewhere
else" is
usually a differently optimized version of the same function.  One
reason to do this is when some speculative optimization we did to the
old version becomes unprofitable, but still remains correct[0].  The
threads executing in that old version are still fine to continue
executing there, but threads that just called into the old version
should instead execute this new version that does not have the same
problematic speculative optimization.  To do this we overwrite the
prologue of the old function with a jump to a runtime stub which in
turn figures out what the newly compiled function is and branches to
it.

[0] A real world example: say we turned a null check followed by a
load into just a load, with a fallback in the SIGSEGV handler; and now
we've realized that the value we're null checking this way *is*
sometimes null.  Taking a SIGSEGV every time the value is null is
correct, but bad for performance so we compile a new "healed" copy of
the same function that does not fall back to the SIGSEGV handler for
that particular null check (but explicitly tests it instead).

-- Sanjoy

On Thu, Apr 7, 2016 at 4:35 PM Sanjoy Das <sanjoy at
playingwithpointers.com>
wrote:
> Hi Eric,
>
> Eric Christopher wrote:
>  > Two things:
>  >
>  > a) I'm not against this
>
> Great!
>
>  > b) So, what's your use case? I've got something I'm idly
working on with
>  > someone else where we want patchable targets in both prologue and
>  > epilogue (and some other places...), and am thinking of how to make
this
>  > someone generic enough to build off of there.
>
> We plan to use this to be able to divert control flow from an LLVM
> compiled function to "somewhere else" where the "somewhere
else" is
> usually a differently optimized version of the same function.  One
>
>
Right. So, I've got a use case that I'm working on over here that uses,
basically, patchable prologue and epilogue and am hoping that this ends up
being general enough for both.

I'll take a look at the patch since you've sent it out, but would really
like to not have to change a lot of how it works. :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160413/ac2929c1/attachment.html>

Thanks for looping me in Eric!

If I was going to suggest anything here, I'd like to think about a more
general approach than a very specific attribute like this. My preference is
something like "patchable-function"="kind,kind,..." (if
that's even
possible). This allows us to have common infrastructure for being able to
implement different kinds of function-level patching routines at the same
time or even just generalising this mechanism with the instrumentation
attribute(s).

It would help probably if I'm able to say more, potentially in the form of
an RFC for what Eric and I are working on. :D

Cheers

On Thu, Apr 14, 2016 at 6:13 AM Eric Christopher <echristo at gmail.com>
wrote:
> On Thu, Apr 7, 2016 at 4:35 PM Sanjoy Das <sanjoy at
playingwithpointers.com>
> wrote:
>
>> Hi Eric,
>>
>> Eric Christopher wrote:
>>  > Two things:
>>  >
>>  > a) I'm not against this
>>
>> Great!
>>
>>  > b) So, what's your use case? I've got something I'm
idly working on
>> with
>>  > someone else where we want patchable targets in both prologue and
>>  > epilogue (and some other places...), and am thinking of how to
make
>> this
>>  > someone generic enough to build off of there.
>>
>> We plan to use this to be able to divert control flow from an LLVM
>> compiled function to "somewhere else" where the
"somewhere else" is
>> usually a differently optimized version of the same function.  One
>>
>>
> Right. So, I've got a use case that I'm working on over here that
uses,
> basically, patchable prologue and epilogue and am hoping that this ends up
> being general enough for both.
>
> I'll take a look at the patch since you've sent it out, but would
really
> like to not have to change a lot of how it works. :)
>
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160414/9b2d8631/attachment.html>