[PATCH] Patchpoint - support symbolic targets.

[Juergen Ributzka]

Hi Lang,

you know that I like this feature, so you won’t hear any objections from me - especially for the experimental version of patchpoint.
We will have to revisit this when we do the “non-experimental” version of the intrinsic (e.g get rid of the bitcast), but that is for another time.

I am only wondering about the materialization part. Should we call the symbol directly and use a trampoline when it is out of range? I thought you already implemented that in RuntimeDyld. That way we could use the same code sequence for all code models.

Cheers,
Juergen

PS: Please also update the patchpoint documentation.


> On Mar 31, 2015, at 5:25 PM, Lang Hames <lhames at gmail.com> wrote:
> 
> Hi All,
> 
> At the moment llvm.patchpoint call targets must be integer constants (e.g. 0xDEADBEEF). This patch adds support for symbolic targets like @foo, which addresses a couple of FIXMEs.
> 
> Making this work just involved teaching FastISel and SelectionDAG to construct the appropriate MI/SDNodes, and teaching the Targets how to lower these to MCInsts. Target support for x86 is included in this patch. Support for other targets should be easy to derive from that.
> 
> With this patch applied, you can write patchpoints of the following form:
> 
> tail call i64 (i64, i32, i8*, i32, ...)*
>   @llvm.experimental.patchpoint.void(i64 9, i32 15,
>     i8* bitcast (i64 (i64, i64)* @foo to i8*),      ; <- Call target
>     i32 2, i64 %p1, i64 %p2)
> 
> and this will generate:
> 
> movabsq $_foo, %r11
> callq   *%r11
> // <nop-padding>
> 
> For integer targets this would have been something like:
> 
> movabsq $0xDEADBEEF, %r11
> callq   *%r11
> // <nop-padding>
> 
> The advantage of symbolic targets, beyond improved readability, is that you can cache the IR or compiled objects and re-use them in contexts where the target address may have changed. For example, objects that use symbolic patchpoints can be cached in Orc/MCJIT object-caches and re-used across JIT invocations.
> 
> Immediate-address targets are still fully supported.
> 
> I don't really see any downside to this patch, but I thought I'd throw it out for general discussion before I go and widen what patchpoint is supposed to support.
> 
> Does anyone see any problem with this idea?
> 
> For the curious, my motivation is that I'd like (eventually) to support patchpoints for JIT re-entry in Orc as an alternative to indirect calls, and I want that transformation to be straightforward. E.g.
> 
> call @not_yet_compiled, ...
> to
> call llvm.patchpoint ..., @not_yet_compiled, ...
> 
> Cheers,
> Lang.
> <symbolic_patchpoints.patch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150401/460fc885/attachment.html>