[llvm-dev] Finding caller-saved registers at a function call site

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 27 13:05:52 PDT 2016


Hi Rob,

Robert Lyerly wrote:
 > At a high level, I'm interested in finding the locations of all values
 > that are live at a given call site.**You can think of it like a
 > debugger, e.g. gdb -- I'd like to be able to unwind the stack, frame by
 > frame, and locate all the live values for each function invocation
 > (i.e., where they are in a function's stack frame/register set) at the
 > function call site.  I'm currently using DWARF metadata to implement the
 > frame unwinding mechanism, similarly to gdb.  I can't use DWARF metadata
 > for live value location information, however, because it only generates
 > location information for named source code variables.  I also need to

Isn't DWARF info best effort (not a rhetorical question -- I don't
actually know)?  Or do you not care about being a 100% precise?

Given that you're interested in finding all values live at a
call-site, why not do just that -- run a liveness analysis over stack
slots and registers?  That should catch compiler temporaries too.

A related question is: are you interested in the *values* or the
*locations* the values are in?  For instance if a specific value (say
the result of a load) is spilled at 0x80(%rsp) and is also present in
%r13 (callee saved register), then do you have to know both the
locations or just one of the two?

 > locate compiler-generated temporaries, hence I've been looking at the
 > StackMap intrinsic [1] to provide live value location information.  It
 > does most of what I need, but it does not tell me where live values
 > stored in registers are spilled to the stack as part of the function
 > call procedure (whether they be in callee- or caller-saved registers) --
 > it simply tells me which registers they are stored in before/after the
 > function call procedure.  That's the impetus for my question.

With stackmaps, is the problem that it tells you e.g. a live value is
present in %r9 (caller saved register), but when unwinding the value
may have been clobbered?  This is something other people have run into
as well -- specifically the distinction between "live on call"
(available just before the call) vs. "live on return" (available after
the callee returns).  I'm hazy on the details, but IIRC if this is a
problem, then you may have problems bigger than just figuring out the
spill slots, since the caller saved register may not actually have
been spilled anywhere (since it does not need to live across the
call).

-- Sanjoy


 > This is *not* a problem for callee-saved registers -- these registers
 > are restored from the stack as part of the call frame unwinding
 > procedure detailed in the DWARF standard [2].  However, I'm left trying
 > to find the locations of the live values that were in caller-saved
 > registers and were spilled to the stack as part of the function call
 > procedure (probably during instruction selection/register allocation,
 > I'm not familiar enough with this process).  I realize that for a
 > MachineInstr for a given call there are no live values in caller-saved
 > registers (as they would be clobbered and lost), but where on the stack
 > were they saved?
 >
 > In a nutshell, I'm trying to figure out where values that couldn't be
 > placed in callee-saved registers (and that were allocated to
 > caller-saved registers) were spilled to the stack as part of the
 > function call procedure.  Hopefully this clarifies things -- thanks!
 >
 > [1] http://llvm.org/docs/StackMaps.html
 > [2] http://dwarfstd.org/doc/DWARF4.pdf, page 140


More information about the llvm-dev mailing list