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

[Andrew Trick]

> On Jul 9, 2015, at 2:04 PM, Juergen Ributzka <juergen at apple.com> wrote:
> 
> 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.

Looks really nice. Do we care about field alignment though?

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

I think the number of patchable bytes should be recorded (including the call itself), but I don’t know exactly how Swaroop is using it.

Andy

> 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/4eb3aa8b/attachment.html>