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

[Eric Christopher via llvm-dev]

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>