Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Juergen Ributzka <juergen <at> apple.com>
Subject: [RFC] New StackMap format proposal (StackMap v2)
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Thursday 9th July 2015 21:04:20 UTC (over 2 years ago)
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
}
 
CD: 3ms