Sanjoy Das via llvm-dev
2016-Apr-06 07:10 UTC
[llvm-dev] 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
Mehdi Amini via llvm-dev
2016-Apr-06 15:11 UTC
[llvm-dev] RFC: New function attribute "patchable-prologue"="<kind>"
> 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
Sanjoy Das via llvm-dev
2016-Apr-06 17:52 UTC
[llvm-dev] RFC: New function attribute "patchable-prologue"="<kind>"
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
Reid Kleckner via llvm-dev
2016-Apr-06 19:44 UTC
[llvm-dev] RFC: New function attribute "patchable-prologue"="<kind>"
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>
Sanjoy Das via llvm-dev
2016-Apr-06 19:47 UTC
[llvm-dev] RFC: New function attribute "patchable-prologue"="<kind>"
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
Sanjoy Das via llvm-dev
2016-Apr-06 19:48 UTC
[llvm-dev] RFC: New function attribute "patchable-prologue"="<kind>"
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
Eric Christopher via llvm-dev
2016-Apr-07 22:26 UTC
[llvm-dev] RFC: New function attribute "patchable-prologue"="<kind>"
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>
Sanjoy Das via llvm-dev
2016-Apr-07 23:35 UTC
[llvm-dev] 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
Maybe Matching Threads
- RFC: New function attribute "patchable-prologue"="<kind>"
- RFC: New function attribute "patchable-prologue"="<kind>"
- RFC: New function attribute "patchable-prologue"="<kind>"
- RFC: New function attribute "patchable-prologue"="<kind>"
- [LLVMdev] Implementing the hotpatch attribute for X86