<br><br><div class="gmail_quote">On Tue, Feb 12, 2013 at 6:48 PM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk" target="_blank">stoklund@2pi.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div class="im"><div><br></div><div><br>On Feb 12, 2013, at 6:37 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br><br></div><blockquote type="cite">
<div class="gmail_quote"><div>For function parameters this is still somewhat of a hack. The correct way to fix this is to change the representation we use for function arguments to use the incoming value and track that for location information - it would obviate the need to scan through the function collecting function parameters as if they were local variables.</div>
</div></blockquote><div><br></div></div><div>The problem is that in C, arguments are variables, so we can't simply track the incoming value. The variable could be reassigned.</div><div><br></div></div></blockquote><div>
<br></div><div>I actually mean the llvm value which we basically copy into an alloca on entry into the function in the front end. We should be able to track any movement of that yes?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div></div><div>Unless DWARF can track the incoming argument value separately from the current variable value?</div><div class="im"><br></div></div></blockquote><div><br></div><div>My idea is that we could track what location it is separately via abi and encode that and then any changes, but I was mostly thinking of not copying the incoming value into an alloca in the front end and rather having the dbg.value reference the function argument rather than the alloca. I'm not sure what changes we'd need to make in allocation to track this though offhand, my guess is some. The dbg.value on entry should have the function argument via the prologue (or we just add them as part of the prologue) which will have the ABI location and then any changes later would be marked by a dbg.value as well if we spilled or killed the argument value (in the case of unused arguments), but we'd be correct at the end of the prologue.</div>
<div><br></div><div>Sound plausible?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div class="im"><blockquote type="cite"><div class="gmail_quote">
<div>Jakob: It looks like we don't need the value renaming machinery any more, i.e.</div>
<div><div><br></div><div>void LiveDebugVariables::renameRegister(unsigned OldReg, unsigned NewReg, unsigned SubIdx)</div></div><div><br></div><div>since I'm guessing the register allocator keeps the virtual register map up to date that we use later when we actually run the pass?</div>
</div>
</blockquote><br></div><div>If the code is really dead, it's fine to delete it. RA uses other LDV functions when spilling and splitting live ranges.</div></div></blockquote><div><br></div><div>Seems so, I couldn't find a use of it anywhere, but you're in that code a lot more than I am :)</div>
<div><br></div><div>-eric </div></div><br>