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

Andrew Trick atrick at apple.com
Thu Jul 9 14:34:38 PDT 2015

On Jul 9, 2015, at 2:19 PM, Andrew Trick <atrick at apple.com> wrote:

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

Never mind. I just noticed that you took care of natural alignment by reserving byte arrays (Reserved [3]) and adding “align to” notes before each set of records.

Andy

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/1fa29b71/attachment.html>

More information about the llvm-dev mailing list