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

[Proposed langref entry]

The "patchable-prologue" attribute on a function is a general
mechanism to control the form of a function's prologue in ways that
make it easy to patch at runtime.

Currently only one value is supported:

# "hotpatch-compact"

If a function is marked with
"patchable-prologue"="hotpatch-compact"
then:

  1. The first instruction of the function is at least two bytes long.
  2. The first two bytes of the first instruction does not span a cache
     line boundary.
  3. The instruction denoted by (1) is preferably not a no-op, i.e.,
     we'd prefer to "re-use" an instruction already present.  For
     instance, we can emit a two byte form of a "push CSR" instruction
     that we'd have needed anyway.

"hotpatch-compact" is useful for runtimes that want to thread-safely
overwrite the first instruction of a function with a short branch.

[End proposed langref entry]


We can consider adding more "schemes" in the future, for instance
"hotpatch-ms" for the Microsoft hotpatching scheme.  I was initially
thinking of proposing "num-patchable-bytes"="<count>"
as the
fundamental building block, but the more I thought about it the less I
liked it, since a specific patching scheme has several tightly
integrated constraints of which the number of bytes is just one.

What do you think?

-- Sanjoy

> On Apr 6, 2016, at 12:10 AM, Sanjoy Das via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> [Proposed langref entry]
> 
> The "patchable-prologue" attribute on a function is a general
> mechanism to control the form of a function's prologue in ways that
> make it easy to patch at runtime.
> 
> Currently only one value is supported:
> 
> # "hotpatch-compact"
> 
> If a function is marked with
"patchable-prologue"="hotpatch-compact"
> then:
> 
> 1. The first instruction of the function is at least two bytes long.
IIRC the motivation is to insert a branch instruction in a thread-safe way?
Isn’t the “two bytes” something that is target specific?

— 
Mehdi
> 2. The first two bytes of the first instruction does not span a cache
>    line boundary.
> 3. The instruction denoted by (1) is preferably not a no-op, i.e.,
>    we'd prefer to "re-use" an instruction already present. 
For
>    instance, we can emit a two byte form of a "push CSR"
instruction
>    that we'd have needed anyway.
> 
> "hotpatch-compact" is useful for runtimes that want to
thread-safely
> overwrite the first instruction of a function with a short branch.
> 
> [End proposed langref entry]
> 
> 
> We can consider adding more "schemes" in the future, for instance
> "hotpatch-ms" for the Microsoft hotpatching scheme.  I was
initially
> thinking of proposing
"num-patchable-bytes"="<count>" as the
> fundamental building block, but the more I thought about it the less I
> liked it, since a specific patching scheme has several tightly
> integrated constraints of which the number of bytes is just one.
> 
> What do you think?
> 
> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Mehdi Amini wrote:
>> On Apr 6, 2016, at 12:10 AM, Sanjoy Das via llvm-dev<llvm-dev at
lists.llvm.org>  wrote:
>>
>> [Proposed langref entry]
>>
>> The "patchable-prologue" attribute on a function is a general
>> mechanism to control the form of a function's prologue in ways that
>> make it easy to patch at runtime.
>>
>> Currently only one value is supported:
>>
>> # "hotpatch-compact"
>>
>> If a function is marked with
"patchable-prologue"="hotpatch-compact"
>> then:
>>
>> 1. The first instruction of the function is at least two bytes long.
>
> IIRC the motivation is to insert a branch instruction in a thread-safe way?
Yes.
> Isn’t the “two bytes” something that is target specific?
Yes, that's a good point.  I can think of two ways to fix this:

  - Change the spec to say "large enough to accommodate a short jump 
instruction"

  - Rename the "hotpatch-compact" scheme to
"hotpatch-compact-x86-64"
and basically live with the fact that it is a target specific attribute.

I like the first one better, but I can live with either since at this 
time I really only care about x86_64.

-- Sanjoy

This looks great to me. I think the attribute using byte sizes was overly
general, but we still want to leave room to implement a few different
patching schemes. Other than your scheme, the obvious ones are the MS one
and one that leaves space for a long jump in the prologue.

I'm assuming this attribute won't affect inlining or other IPO in any
way,
but you should probably mention that in the langref.

On Wed, Apr 6, 2016 at 12:10 AM, Sanjoy Das <sanjoy at
playingwithpointers.com>
wrote:
> [Proposed langref entry]
>
> The "patchable-prologue" attribute on a function is a general
> mechanism to control the form of a function's prologue in ways that
> make it easy to patch at runtime.
>
> Currently only one value is supported:
>
> # "hotpatch-compact"
>
> If a function is marked with
"patchable-prologue"="hotpatch-compact"
> then:
>
>  1. The first instruction of the function is at least two bytes long.
>  2. The first two bytes of the first instruction does not span a cache
>     line boundary.
>  3. The instruction denoted by (1) is preferably not a no-op, i.e.,
>     we'd prefer to "re-use" an instruction already present. 
For
>     instance, we can emit a two byte form of a "push CSR"
instruction
>     that we'd have needed anyway.
>
> "hotpatch-compact" is useful for runtimes that want to
thread-safely
> overwrite the first instruction of a function with a short branch.
>
> [End proposed langref entry]
>
>
> We can consider adding more "schemes" in the future, for instance
> "hotpatch-ms" for the Microsoft hotpatching scheme.  I was
initially
> thinking of proposing
"num-patchable-bytes"="<count>" as the
> fundamental building block, but the more I thought about it the less I
> liked it, since a specific patching scheme has several tightly
> integrated constraints of which the number of bytes is just one.
>
> What do you think?
>
> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160406/5dd11bad/attachment.html>

Reid Kleckner wrote:
> This looks great to me. I think the attribute using byte sizes was
> overly general, but we still want to leave room to implement a few
> different patching schemes. Other than your scheme, the obvious ones are
> the MS one and one that leaves space for a long jump in the prologue.
Agreed.
> I'm assuming this attribute won't affect inlining or other IPO in
any
> way, but you should probably mention that in the langref.
I've built a bad reputation for myself, haven't I? ;)

-- Sanjoy

Reid Kleckner wrote:
> I'm assuming this attribute won't affect inlining or other IPO in
any
> way, but you should probably mention that in the langref.
To directly answer this, this is just a *mechanism* to implement 
linkonce_odr type linkage.  This in itself does not imply in IPO 
restrictions, that should come directly from the linkage type.

-- Sanjoy

Two things:

a) I'm not against this
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.

Thoughts?

-eric

On Wed, Apr 6, 2016 at 12:11 AM Sanjoy Das via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> [Proposed langref entry]
>
> The "patchable-prologue" attribute on a function is a general
> mechanism to control the form of a function's prologue in ways that
> make it easy to patch at runtime.
>
> Currently only one value is supported:
>
> # "hotpatch-compact"
>
> If a function is marked with
"patchable-prologue"="hotpatch-compact"
> then:
>
>   1. The first instruction of the function is at least two bytes long.
>   2. The first two bytes of the first instruction does not span a cache
>      line boundary.
>   3. The instruction denoted by (1) is preferably not a no-op, i.e.,
>      we'd prefer to "re-use" an instruction already present. 
For
>      instance, we can emit a two byte form of a "push CSR"
instruction
>      that we'd have needed anyway.
>
> "hotpatch-compact" is useful for runtimes that want to
thread-safely
> overwrite the first instruction of a function with a short branch.
>
> [End proposed langref entry]
>
>
> We can consider adding more "schemes" in the future, for instance
> "hotpatch-ms" for the Microsoft hotpatching scheme.  I was
initially
> thinking of proposing
"num-patchable-bytes"="<count>" as the
> fundamental building block, but the more I thought about it the less I
> liked it, since a specific patching scheme has several tightly
> integrated constraints of which the number of bytes is just one.
>
> What do you think?
>
> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160407/386d17e7/attachment.html>

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