[LLVMdev] [RFC] New StackMap format proposal (StackMap v2)

[Andrew Trick]

> On Jul 9, 2015, at 6:37 PM, Kevin Modzelewski <kevmod at gmail.com> wrote:
> 
> 
> 
> On Thu, Jul 9, 2015 at 4:36 PM, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote:
> 
>> On Jul 9, 2015, at 3:33 PM, Swaroop Sridhar <Swaroop.Sridhar at microsoft.com <mailto:Swaroop.Sridhar at microsoft.com>> wrote:
>> 
>> Regarding Call-site size specification:
>> 
>>  
>> 
>> CoreCLR (https://github.com/dotnet/coreclr <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dotnet_coreclr&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=k9ShSbtyr8PTV_wAD6k1EUBN_L1NHV7z4gRzkd7hkTI&s=1wT7U5rYG7gu4VYtJjOjaV6LRfcapEjNmOCYQ84EjTk&e=>) requires the size of the Call-instruction to be reported in the GCInfo encoding.
>> 
>>  
>> 
>> The runtime performs querries for StackMap records using instruction offsets as follows:
>> 
>> 1)      Offset at the end of the call instruction (offset of next instruction-1) if the call instruction occurs in code where GC can only take control at safe-points.
>> 
> 
> As part of this change it would be great if LLVM could now guarantee that the call will be emitted at the end of the patchable space. It currently happens to emit at the beginning, but makes no guarantee. Emitting at the end works better for tracking the return address.
> 
> I think for this to be reliable, we'd have to make the stackmap locations be valid to the end of the patchpoint, instead of only to the beginning of the patchpoint.  If we don't, the caller still has to be ready to move the call instruction to make room for any spills+restores of non-preserved registers used by the stackmap.

Yes, we talked about specifying the register save convention as part of the patchpoint. It’s a separate but related feature. The point is that LLVM should probably emit the call at the end for those cases when the JIT doesn’t have to generate its own call sequence.

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150710/11662a52/attachment.html>