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

[Hal Finkel]

----- Original Message -----
> From: "Juergen Ributzka" <juergen at apple.com>
> To: "LLVM Dev" <llvmdev at cs.uiuc.edu>
> Cc: "Lang Hames" <lhames at apple.com>
> Sent: Thursday, July 9, 2015 4:04:20 PM
> Subject: [LLVMdev] [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
> }

Do you guarantee that these will appear in order of increasing instruction offset?

 -Hal

> 
> 
> 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
> }
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory