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

Tue Jun 28 06:59:10 PDT 2016

Hi Sanjoy,

On Mon, Jun 27, 2016 at 4:05 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> 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?
>
>
Yes, tracking live values using DWARF metadata is best-effort, another
reason that it is not suitable for what I'm doing :).  The DWARF unwinding
procedure, however, seems to be trivial to implement correctly, as it's
literally just dumping metadata about the generated prologue.  I haven't
had any correctness or incompleteness problems yet with using this aspect
of the DWARF standard.

> 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.
>
>
The reason I can't just run a liveness analysis over stack slots and
registers in the backend is that I'm trying to map live value locations
back up into their corresponding values in LLVM bitcode.  This is why I'm
using the stackmap intrinsic, as it does exactly that -- provides a mapping
between a bitcode value and its storage location for the generated
assembly.  I need this intermediate-level value because I'm doing ABI
translation.  I'm plucking values out of a call frame laid out in one ABI
and storing them in a destination stack frame that is laid out according to
another ABI.  The IR value is essentially the "key" used to match
corresponding storage locations across the two ABIs.  I'm transforming a
thread's current stack laid out for one ABI into one laid out for another
ABI.

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

I'm actually only interested in being able to find values; I don't
particularly care about where they're stored.  In your hypothetical, as
long as the compiler could tell me that the value was stored in one of
those locations, that'd be okay.

>
> > 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).
>

I'm not concerned about values that are not live across the call ("live on
call"), only those that are live after returning from the call ("live on
return").  If the value is not live after the call, there's no need for me
to able to recover it.  I just need to be able to resume execution in that
function correctly, so I'm only concerned about values in caller-saved
registers that are needed after the call completes, and therefore have been
spilled to the stack as part of the procedure call standard.

Because I'm rewriting the stack to change the ABI, I need to be able to set
up the stack so that execution can correctly unwind back up the call
chain.  This means that I need to be able to populate spill stack slots for
caller-saved registers, hence this is why I need their locations.

Thanks again for your help!

> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160628/98b2f1a5/attachment.html>