<div dir="ltr"><div><div>I think I understand where the spill code is getting generated. I've been digging through the register allocation debug information, and I see that the register allocator itself is generating the spill code around the call site (the greedy allocator is also splitting the virtual register's live range around the call site). I don't care about the internals of the register allocator, but I see that it produces a VirtRegMap which contains the mapping of virtual registers to physical registers/spill slots. I have two questions about this:<br><br></div>1. Is there a way to access the produced VirtRegMap in the architecture-specific AsmPrinter? I tried the normal getAnalysis<VirtRegMap>, but it produces and empty mapping.<br></div>2. If I manage to get access to this mapping, is there a way to correlate an LLVM bitcode Value to a virtual register?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 28, 2016 at 9:59 AM, Robert Lyerly <span dir="ltr"><<a href="mailto:rlyerly@vt.edu" target="_blank">rlyerly@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi Sanjoy,<br></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Jun 27, 2016 at 4:05 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Rob,<span><br>
<br>
Robert Lyerly wrote:<br>
> At a high level, I'm interested in finding the locations of all values<br></span>
> that are live at a given call site.**You can think of it like a<span><br>
> debugger, e.g. gdb -- I'd like to be able to unwind the stack, frame by<br>
> frame, and locate all the live values for each function invocation<br>
> (i.e., where they are in a function's stack frame/register set) at the<br>
> function call site. I'm currently using DWARF metadata to implement the<br>
> frame unwinding mechanism, similarly to gdb. I can't use DWARF metadata<br>
> for live value location information, however, because it only generates<br>
> location information for named source code variables. I also need to<br>
<br></span>
Isn't DWARF info best effort (not a rhetorical question -- I don't<br>
actually know)? Or do you not care about being a 100% precise?<br>
<br></blockquote></span><div><br>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.<br> </div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Given that you're interested in finding all values live at a<br>
call-site, why not do just that -- run a liveness analysis over stack<br>
slots and registers? That should catch compiler temporaries too.<br>
<br></blockquote></span><div><br>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.<br> </div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A related question is: are you interested in the *values* or the<br>
*locations* the values are in? For instance if a specific value (say<br>
the result of a load) is spilled at 0x80(%rsp) and is also present in<br>
%r13 (callee saved register), then do you have to know both the<br>
locations or just one of the two?<span><br></span></blockquote></span><div><br>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.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
<br>
> locate compiler-generated temporaries, hence I've been looking at the<br>
> StackMap intrinsic [1] to provide live value location information. It<br>
> does most of what I need, but it does not tell me where live values<br>
> stored in registers are spilled to the stack as part of the function<br>
> call procedure (whether they be in callee- or caller-saved registers) --<br>
> it simply tells me which registers they are stored in before/after the<br>
> function call procedure. That's the impetus for my question.<br>
<br></span>
With stackmaps, is the problem that it tells you e.g. a live value is<br>
present in %r9 (caller saved register), but when unwinding the value<br>
may have been clobbered? This is something other people have run into<br>
as well -- specifically the distinction between "live on call"<br>
(available just before the call) vs. "live on return" (available after<br>
the callee returns). I'm hazy on the details, but IIRC if this is a<br>
problem, then you may have problems bigger than just figuring out the<br>
spill slots, since the caller saved register may not actually have<br>
been spilled anywhere (since it does not need to live across the<br>
call).<br></blockquote><div><br></div></span><div>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.<br></div><div><br></div><div>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.<br><br>Thanks again for your help!<br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- Sanjoy<br>
<br>
<br>
> This is *not* a problem for callee-saved registers -- these registers<div><div><br>
> are restored from the stack as part of the call frame unwinding<br>
> procedure detailed in the DWARF standard [2]. However, I'm left trying<br>
> to find the locations of the live values that were in caller-saved<br>
> registers and were spilled to the stack as part of the function call<br>
> procedure (probably during instruction selection/register allocation,<br>
> I'm not familiar enough with this process). I realize that for a<br>
> MachineInstr for a given call there are no live values in caller-saved<br>
> registers (as they would be clobbered and lost), but where on the stack<br>
> were they saved?<br>
><br>
> In a nutshell, I'm trying to figure out where values that couldn't be<br>
> placed in callee-saved registers (and that were allocated to<br>
> caller-saved registers) were spilled to the stack as part of the<br>
> function call procedure. Hopefully this clarifies things -- thanks!<br>
><br>
> [1] <a href="http://llvm.org/docs/StackMaps.html" rel="noreferrer" target="_blank">http://llvm.org/docs/StackMaps.html</a><br>
> [2] <a href="http://dwarfstd.org/doc/DWARF4.pdf" rel="noreferrer" target="_blank">http://dwarfstd.org/doc/DWARF4.pdf</a>, page 140<br>
</div></div></blockquote></span></div><br></div></div></div></div>
</blockquote></div><br></div>