[LLVMdev] [RFC] New StackMap format proposal (StackMap v2)
Kevin Modzelewski
kevmod at gmail.com
Thu Jul 9 18:37:26 PDT 2015
On Thu, Jul 9, 2015 at 4:36 PM, Andrew Trick <atrick at apple.com> wrote:
>
> On Jul 9, 2015, at 3:33 PM, Swaroop Sridhar <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150709/ede8d7f4/attachment.html>
More information about the llvm-dev
mailing list