[llvm-dev] RFC: New function attribute "patchable-prologue"="<kind>"

Eric Christopher via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 14 13:36:13 PDT 2016


On Thu, Apr 14, 2016 at 6:45 AM Dean Michael Berris <dberris at google.com>
wrote:

> 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
>
>
Yeah, we're almost there right? Sanjoy is jumping the gun on us a bit :)

patchable-function is a fairly terrible name, but an enum list of valid
kinds seems to work for me. We might end up having to make it an exclusive
list rather than a combined list due to people wanting different size
patchable areas.

-eric



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


More information about the llvm-dev mailing list