thr3ads.net - llvm dev - [LLVMdev] [RFC] New StackMap format proposal (StackMap v2) [Jul 2015]

If this information is useful, please help other people find it:
Share via:

Andrew Trick

2015-Jul-09 23:36 UTC

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

> 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://github.com/dotnet/coreclr>) 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.
> 2)      Offset of the start of the call instruction if the call instruction
occurs within a code-range that allows full interruption (that is, all
instructions in a range are considered safe-points)
If the JIT requires knowledge of call's encoding, it should probably be
emitting the call instruction itself within the patchable space reserved by
LLVM.

Note that the patchpoint may include a mov in addition to call, so the
patchpoint address is not the same as the call address.
>  
> LLVM/statepoint GC does not support option (2), but the CoreCLR’s GC-table
Encoding has an interface designed to suite both modes.
> void DefineCallSites(UINT32* pCallSites, BYTE* pCallSiteSizes, UINT32
numCallSites)
>  
> Therefore, it is helpful to have Call-Site size specified in
StackMapRecord.
> I agree with Andy, that the call-site size should include all bytes between
the start of the call instruction and the start of the next instruction.
I suggested this because we want to support a dynamic callback that determines
the patchpoint size (given the set of register arguments), and it would be nice
to record that decision within the stack map. This is important information for
any code that is responsible for patching because it must patch over all
reserved bytes.

The alternative would be for LLVM to emit the call at the end and record just
the size of the call instruction encoding. That seems like a silly, x86-specific
waste of stackmap space though. The JIT can either do the encoding and keep
track of the info, or a small nop+move_immediate decoder can figure it out for
all reasonable cases.

Andy
>  
> Thanks,
> Swaroop.
>  
> From: Juergen Ributzka [mailto:juergen at apple.com] 
> Sent: Thursday, July 9, 2015 2:04 PM
> To: LLVM Dev
> Cc: Lang Hames; Andrew Trick; Phil Pizlo; Philip Reames; Sanjoy Das;
Swaroop Sridhar; Russell Hadley
> Subject: [RFC] New StackMap format proposal (StackMap v2)
>  
> Hi @ll,
>  
> over the past year we gained more experience with the
patchpoint/stackmap/statepoint intrinsics and it exposed limitations in the
stackmap format.
> The following proposal includes feedback and request from several
interested parties and I would like to hear your feedback.
>  
> Missing correlation between functions and stackmap records:
> Originally the client had to keep track of the ID to know which stackmap
record belongs to which function, but this would stop working once functions are
inlined.
> The new format fixes that by adding a direct reference from the function to
the stackmap records.
>  
> Call Size and Function Size:
> These are additional information that are of interest and have been added
to the format.
> @Swaroop: Could you please provide a little more detailed explanation on
the "Call Size" field and what exactly is there recorded. Is it just
the call instruction
> or also the materialization code for the address? For what is this used
for?
>  
> Flat format:
> We think moving to a flat form will make parsing easier, because every
record has a fixed size and offsets can be calculated easily. The plan is to
also
> provide parsers for both stackmap versions (there is already one for the
first format in tree) and a corresponding C-API to make it easier for clients to
> adopt the new format. There is no plan to drop the original format and we
will continue to support both formats. I will ask for feedback on the C API in a
> separate RFC. 
>  
> Another benefit we hope to achieve from this format is to optimize for size
by uniquing entries - but that is independent optimization and not required.
>  
> More detailed frame record:
> Clients require more information about the function frame, such as spilled
registers, etc. The frame base register i.e. might change when dynamic stack
> realignment is performed on X86.
>  
>  
> If there is anything missing please let me know.
>  
> Thanks
>  
> Cheers,
> Juergen
>  
>  
> Header v2 {
>   uint8  : Stack Map Version (2)
>   uint8  : Reserved [3] (0)
>   uint32 : Constants Offset (bytes)
>   uint32 : Frame Records Offset (bytes)
>   uint32 : Frame Registers Offset (bytes)
>   uint32 : StackMap Records Offset (bytes)
>   uint32 : Locations Offset (bytes)
>   uint32 : LiveOuts Offset (bytes)
> }
> 
> align to 8 bytes
> Constants[] {
>   uint64 : LargeConstant
> }
> 
> align to 8 bytes
> FrameRecord[] {
>   uint64 : Function Address
>   uint32 : Function Size
>   uint32 : Stack Size
>   uint16 : Flags {
>     bool : HasFrame
>     bool : HasVariableSizeAlloca
>     bool : HasStackRealignment
>     bool : HasLiveOutInfo
>     bool : Reserved [12]
>   }
>   uint16 : Frame Base Register Dwarf RegNum
>   uint16 : Num Frame Registers
>   uint16 : Frame Register Index
>   uint16 : Num StackMap Records
>   uint16 : StackMap Record Index
> }
> 
> align to 4 bytes
> FrameRegister[] {
>   uint16 : Dwarf RegNum
>   int16  : Offset
>   uint8  : Size in Bytes
>   uint8  : Flags {
>     bool : IsSpilled
>     bool : Reserved [7]
>   }
> }
> 
> align to 8 bytes
> StackMapRecord[] {
>   uint64 : PatchPoint ID
>   uint32 : Instruction Offset
>   uint8  : Call size (bytes)
>   uint8  : Flags {
>     bool : HasLiveOutInfo
>     bool : Reserved [7]
>   }
>   uint16 : Num Locations
>   uint16 : Location Index
>   uint16 : Num LiveOuts
>   uint16 : LiveOut Index
> }
>  
> align to 4 bytes
> Location[] {
>   uint8  : Register | Direct | Indirect | Constant | ConstantIndex
>   uint8  : Reserved (location flags)
>   uint16 : Dwarf RegNum
>   int32  : Offset or SmallConstant
> }
> 
> align to 2 bytes
> LiveOuts[] {
>   uint16 : Dwarf RegNum
>   uint8  : Reserved
>   uint8  : Size in Bytes
> }
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150709/702ea78e/attachment.html>

Swaroop Sridhar

2015-Jul-10 00:54 UTC

head link

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

My comments are inline.

Swaroop.

From: Andrew Trick [mailto:atrick at apple.com]
Sent: Thursday, July 9, 2015 4:36 PM
To: Swaroop Sridhar
Cc: Juergen Ributzka; LLVM Dev; Lang Hames; Phil Pizlo; Philip Reames; Sanjoy
Das; Russell Hadley
Subject: Re: [RFC] New StackMap format proposal (StackMap v2)

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) 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 second emitting the call-instruction at the end of the patch-space.

2)      Offset of the start of the call instruction if the call instruction
occurs within a code-range that allows full interruption (that is, all
instructions in a range are considered safe-points)

If the JIT requires knowledge of call's encoding, it should probably be
emitting the call instruction itself within the patchable space reserved by
LLVM.

Note that the patchpoint may include a mov in addition to call, so the
patchpoint address is not the same as the call address.

LLVM/statepoint GC does not support option (2), but the CoreCLR’s GC-table
Encoding has an interface designed to suite both modes.
void DefineCallSites(UINT32* pCallSites, BYTE* pCallSiteSizes, UINT32
numCallSites)

Therefore, it is helpful to have Call-Site size specified in StackMapRecord.
I agree with Andy, that the call-site size should include all bytes between the
start of the call instruction and the start of the next instruction.

I suggested this because we want to support a dynamic callback that determines
the patchpoint size (given the set of register arguments), and it would be nice
to record that decision within the stack map. This is important information for
any code that is responsible for patching because it must patch over all
reserved bytes.

The alternative would be for LLVM to emit the call at the end and record just
the size of the call instruction encoding. That seems like a silly, x86-specific
waste of stackmap space though. The JIT can either do the encoding and keep
track of the info, or a small nop+move_immediate decoder can figure it out for
all reasonable cases.

I agree here too.  CallSiteSize should record the size of the entire patch-point
– to facilitate versatile use of the CallSiteSize field.
Recording just the size of the call-instruction breaks the patchpoint
abstraction.

Given the size of the patchpoint, a Jit needing just the Call-Instruction size
can do a local decoding as you’ve suggested.

Andy

Thanks,
Swaroop.

From: Juergen Ributzka [mailto:juergen at apple.com]
Sent: Thursday, July 9, 2015 2:04 PM
To: LLVM Dev
Cc: Lang Hames; Andrew Trick; Phil Pizlo; Philip Reames; Sanjoy Das; Swaroop
Sridhar; Russell Hadley
Subject: [RFC] New StackMap format proposal (StackMap v2)

Hi @ll,

over the past year we gained more experience with the
patchpoint/stackmap/statepoint intrinsics and it exposed limitations in the
stackmap format.
The following proposal includes feedback and request from several interested
parties and I would like to hear your feedback.

Missing correlation between functions and stackmap records:
Originally the client had to keep track of the ID to know which stackmap record
belongs to which function, but this would stop working once functions are
inlined.
The new format fixes that by adding a direct reference from the function to the
stackmap records.

Call Size and Function Size:
These are additional information that are of interest and have been added to the
format.
@Swaroop: Could you please provide a little more detailed explanation on the
"Call Size" field and what exactly is there recorded. Is it just the
call instruction
or also the materialization code for the address? For what is this used for?

Flat format:
We think moving to a flat form will make parsing easier, because every record
has a fixed size and offsets can be calculated easily. The plan is to also
provide parsers for both stackmap versions (there is already one for the first
format in tree) and a corresponding C-API to make it easier for clients to
adopt the new format. There is no plan to drop the original format and we will
continue to support both formats. I will ask for feedback on the C API in a
separate RFC.

Another benefit we hope to achieve from this format is to optimize for size by
uniquing entries - but that is independent optimization and not required.

More detailed frame record:
Clients require more information about the function frame, such as spilled
registers, etc. The frame base register i.e. might change when dynamic stack
realignment is performed on X86.

If there is anything missing please let me know.

Thanks

Cheers,
Juergen

Header v2 {
  uint8  : Stack Map Version (2)
  uint8  : Reserved [3] (0)
  uint32 : Constants Offset (bytes)
  uint32 : Frame Records Offset (bytes)
  uint32 : Frame Registers Offset (bytes)
  uint32 : StackMap Records Offset (bytes)
  uint32 : Locations Offset (bytes)
  uint32 : LiveOuts Offset (bytes)
}

align to 8 bytes
Constants[] {
  uint64 : LargeConstant
}

align to 8 bytes
FrameRecord[] {
  uint64 : Function Address
  uint32 : Function Size
  uint32 : Stack Size
  uint16 : Flags {
    bool : HasFrame
    bool : HasVariableSizeAlloca
    bool : HasStackRealignment
    bool : HasLiveOutInfo
    bool : Reserved [12]
  }
  uint16 : Frame Base Register Dwarf RegNum
  uint16 : Num Frame Registers
  uint16 : Frame Register Index
  uint16 : Num StackMap Records
  uint16 : StackMap Record Index
}

align to 4 bytes
FrameRegister[] {
  uint16 : Dwarf RegNum
  int16  : Offset
  uint8  : Size in Bytes
  uint8  : Flags {
    bool : IsSpilled
    bool : Reserved [7]
  }
}

align to 8 bytes
StackMapRecord[] {
  uint64 : PatchPoint ID
  uint32 : Instruction Offset
  uint8  : Call size (bytes)
  uint8  : Flags {
    bool : HasLiveOutInfo
    bool : Reserved [7]
  }
  uint16 : Num Locations
  uint16 : Location Index
  uint16 : Num LiveOuts
  uint16 : LiveOut Index
}

align to 4 bytes
Location[] {
  uint8  : Register | Direct | Indirect | Constant | ConstantIndex
  uint8  : Reserved (location flags)
  uint16 : Dwarf RegNum
  int32  : Offset or SmallConstant
}

align to 2 bytes
LiveOuts[] {
  uint16 : Dwarf RegNum
  uint8  : Reserved
  uint8  : Size in Bytes
}

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

Kevin Modzelewski

2015-Jul-10 01:37 UTC

head link

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

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>

Andrew Trick

2015-Jul-10 16:41 UTC

head link

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

> 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>

Philip Reames

2015-Jul-15 05:34 UTC

head link

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

On 07/09/2015 04:36 PM, Andrew Trick 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) 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.This sounds reasonable.  I can't see an immediate reason why this would 
restrict future implementation flexibility.>
>> 2)Offset of the start of the call instruction if the call instruction 
>> occurs within a code-range that allows full interruption (that is, 
>> all instructions in a range are considered safe-points)
>>
>
> If the JIT requires knowledge of call's encoding, it should probably 
> be emitting the call instruction itself within the patchable space 
> reserved by LLVM.
>
> Note that the patchpoint may include a mov in addition to call, so the 
> patchpoint address is not the same as the call address.Just to be clear, the problem with (2) has nothing to do with 
StackMaps.  It has to do with the fact our entire backend confuses 
pointers and non-pointers.  To have option (2), I believe we'd need to 
effectively have a stackmap for every instruction.  That's a lot more 
work than anyone has serious proposed to date.  :)>
>> LLVM/statepoint GC does not support option (2), but the CoreCLR’s 
>> GC-table Encoding has an interface designed to suite both modes.
>>
>> void DefineCallSites(UINT32* pCallSites, BYTE* pCallSiteSizes, 
>> UINT32numCallSites)
>>
>> Therefore, it is helpful to have Call-Site size specified in 
>> StackMapRecord.
>>
>> I agree with Andy, that the call-site size should include all bytes 
>> between the start of the call instruction and the start of the next 
>> instruction.
>>
>
> I suggested this because we want to support a dynamic callback that 
> determines the patchpoint size (given the set of register arguments), 
> and it would be nice to record that decision within the stack map. 
> This is important information for any code that is responsible for 
> patching because it must patch over all reserved bytes.
>
> The alternative would be for LLVM to emit the call at the end and 
> record just the size of the call instruction encoding. That seems like 
> a silly, x86-specific waste of stackmap space though. The JIT can 
> either do the encoding and keep track of the info, or a small 
> nop+move_immediate decoder can figure it out for all reasonable cases.I would argue in favor of recording the number of bytes recorded for 
patching.  I think that gives us everything we need in practice. Any 
non-destructive or concurrent patch mechanism is going to need extremely 
fine grained control anyways.  Trying to do that partly within LLVM and 
partly without just seems like a mistake.>
> Andy
>
>> Thanks,
>>
>> Swaroop.
>>
>> *From:*Juergen Ributzka [mailto:juergen at apple.com]
>> *Sent:* Thursday, July 9, 2015 2:04 PM
>> *To:* LLVM Dev
>> *Cc:* Lang Hames; Andrew Trick; Phil Pizlo; Philip Reames; Sanjoy 
>> Das; Swaroop Sridhar; Russell Hadley
>> *Subject:* [RFC] New StackMap format proposal (StackMap v2)
>>
>> Hi @ll,
>>
>> over the past year we gained more experience with the 
>> patchpoint/stackmap/statepoint intrinsics and it exposed limitations 
>> in the stackmap format.
>>
>> The following proposal includes feedback and request from several 
>> interested parties and I would like to hear your feedback.
>>
>> Missing correlation between functions and stackmap records:
>>
>> Originally the client had to keep track of the ID to know which 
>> stackmap record belongs to which function, but this would stop 
>> working once functions are inlined.
>>
>> The new format fixes that by adding a direct reference from the 
>> function to the stackmap records.
>>
>> Call Size and Function Size:
>>
>> These are additional information that are of interest and have been 
>> added to the format.
>>
>> @Swaroop: Could you please provide a little more detailed explanation 
>> on the "Call Size" field and what exactly is there recorded.
Is it
>> just the call instruction
>>
>> or also the materialization code for the address? For what is this 
>> used for?
>>
>> Flat format:
>>
>> We think moving to a flat form will make parsing easier, because 
>> every record has a fixed size and offsets can be calculated easily. 
>> The plan is to also
>>
>> provide parsers for both stackmap versions (there is already one for 
>> the first format in tree) and a corresponding C-API to make it easier 
>> for clients to
>>
>> adopt the new format. There is no plan to drop the original format 
>> and we will continue to support both formats. I will ask for feedback 
>> on the C API in a
>>
>> separate RFC.
>>
>> Another benefit we hope to achieve from this format is to optimize 
>> for size by uniquing entries - but that is independent optimization 
>> and not required.
>>
>> More detailed frame record:
>>
>> Clients require more information about the function frame, such as 
>> spilled registers, etc. The frame base register i.e. might change 
>> when dynamic stack
>>
>> realignment is performed on X86.
>>
>> If there is anything missing please let me know.
>>
>> Thanks
>>
>> Cheers,
>>
>> Juergen
>>
>> Header v2 {
>>   uint8  : Stack Map Version (2)
>>   uint8  : Reserved [3] (0)
>>   uint32 : Constants Offset (bytes)
>>   uint32 : Frame Records Offset (bytes)
>>   uint32 : Frame Registers Offset (bytes)
>>   uint32 : StackMap Records Offset (bytes)
>>   uint32 : Locations Offset (bytes)
>>   uint32 : LiveOuts Offset (bytes)
>>
>> }
>>
>> align to 8 bytes
>> Constants[] {
>>   uint64 : LargeConstant
>> }
>>
>> align to 8 bytes
>> FrameRecord[] {
>>   uint64 : Function Address
>>   uint32 : Function Size
>>   uint32 : Stack Size
>>   uint16 : Flags {
>>     bool : HasFrame
>>     bool : HasVariableSizeAlloca
>>     bool : HasStackRealignment
>>     bool : HasLiveOutInfo
>>     bool : Reserved [12]
>>   }
>>   uint16 : Frame Base Register Dwarf RegNum
>>   uint16 : Num Frame Registers
>>   uint16 : Frame Register Index
>>   uint16 : Num StackMap Records
>>   uint16 : StackMap Record Index
>>
>> }
>>
>> align to 4 bytes
>> FrameRegister[] {
>>   uint16 : Dwarf RegNum
>>   int16  : Offset
>>   uint8  : Size in Bytes
>>   uint8  : Flags {
>>     bool : IsSpilled
>>     bool : Reserved [7]
>>   }
>> }
>>
>> align to 8 bytes
>> StackMapRecord[] {
>>   uint64 : PatchPoint ID
>>   uint32 : Instruction Offset
>>   uint8  : Call size (bytes)
>>   uint8  : Flags {
>>     bool : HasLiveOutInfo
>>     bool : Reserved [7]
>>   }
>>   uint16 : Num Locations
>>   uint16 : Location Index
>>   uint16 : Num LiveOuts
>>   uint16 : LiveOut Index
>> }
>>
>> align to 4 bytes
>>
>> Location[] {
>>   uint8  : Register | Direct | Indirect | Constant | ConstantIndex
>>   uint8  : Reserved (location flags)
>>   uint16 : Dwarf RegNum
>>   int32  : Offset or SmallConstant
>> }
>>
>> align to 2 bytes
>> LiveOuts[] {
>>   uint16 : Dwarf RegNum
>>   uint8  : Reserved
>>   uint8  : Size in Bytes
>> }
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150714/42c68a13/attachment.html>

Swaroop Sridhar

2015-Jul-16 01:12 UTC

head link

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

Please see inline.

From: Philip Reames [mailto:listmail at philipreames.com]
Sent: Tuesday, July 14, 2015 10:35 PM
To: Andrew Trick; Swaroop Sridhar
Cc: Juergen Ributzka; LLVM Dev; Lang Hames; Phil Pizlo; Sanjoy Das; Russell
Hadley
Subject: Re: [RFC] New StackMap format proposal (StackMap v2)

[…]

1)      Offset of the start of the call instruction if the call instruction
occurs within a code-range that allows full interruption (that is, all
instructions in a range are considered safe-points)

If the JIT requires knowledge of call's encoding, it should probably be
emitting the call instruction itself within the patchable space reserved by
LLVM.

Note that the patchpoint may include a mov in addition to call, so the
patchpoint address is not the same as the call address.

Just to be clear, the problem with (2) has nothing to do with StackMaps.  It has
to do with the fact our entire backend confuses pointers and non-pointers.  To
have option (2), I believe we'd need to effectively have a stackmap for
every instruction.  That's a lot more work than anyone has serious proposed
to date.  :)

Yes. Fully interruptible code will effectively need a StackMap at every
instruction.
Many compilers targeting CLR runtime generate fully-interruptible code ranges
for performance critical code (ex: hot loops where it is very expensive to place
a safepoint-poll to yield control to the GC). CLR GCTables use certain compact
representation techniques so that the image size stays small.
Anyway, I did not mean to suggest that LLVM should support for
fully-interruptible code – at least not in the short term.

[…]

Therefore, it is helpful to have Call-Site size specified in StackMapRecord.
I agree with Andy, that the call-site size should include all bytes between the
start of the call instruction and the start of the next instruction.

I suggested this because we want to support a dynamic callback that determines
the patchpoint size (given the set of register arguments), and it would be nice
to record that decision within the stack map. This is important information for
any code that is responsible for patching because it must patch over all
reserved bytes.

The alternative would be for LLVM to emit the call at the end and record just
the size of the call instruction encoding. That seems like a silly, x86-specific
waste of stackmap space though. The JIT can either do the encoding and keep
track of the info, or a small nop+move_immediate decoder can figure it out for
all reasonable cases.
I would argue in favor of recording the number of bytes recorded for patching. 
I think that gives us everything we need in practice.  Any non-destructive or
concurrent patch mechanism is going to need extremely fine grained control
anyways.  Trying to do that partly within LLVM and partly without just seems
like a mistake.

To clarify my understanding of your proposal,
If we have a statepoint intrinsic, whose call instruction encodes to 5 bytes.
Will the call-site size recorded in the StackMap be:

(a)    5 bytes, if the num-patch-bytes argument to the statepoint is 0

(b)   10 bytes,  if the num-patch-bytes argument to the statepoint is 10?

Thanks,
Swaroop.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150716/876864e2/attachment.html>

llvm dev - Jul 2015 - [LLVMdev] [RFC] New StackMap format proposal (StackMap v2)

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

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

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

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

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

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