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

[Reid Kleckner via llvm-dev]

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>