Here's the bug report that exists for this as well:<div><br></div><div><a href="http://llvm.org/bugs/show_bug.cgi?id=14575">http://llvm.org/bugs/show_bug.cgi?id=14575</a></div><div><br></div><div>-eric<br><br><div class="gmail_quote">
On Tue, Feb 12, 2013 at 6:37 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Tue, Feb 12, 2013 at 5:14 PM, Manman Ren <span dir="ltr"><<a href="mailto:mren@apple.com" target="_blank">mren@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Author: mren<br>
Date: Tue Feb 12 19:14:49 2013<br>
New Revision: 175023<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=175023&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=175023&view=rev</a><br>
Log:<br>
Debug Info: LiveDebugVarible can remove DBG_VALUEs, make sure we emit them back.<br>
<br>
RegisterCoalescer used to depend on LiveDebugVariable. LDV removes DBG_VALUEs<br>
without emitting them at the end.<br>
<br></blockquote><div><br></div></div><div>This isn't quite what's going on, it's mostly that we kept adding all the information and then never bothered to emit it.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


We fix this by removing LDV from RegisterCoalescer. Also add an assertion to<br>
make sure we call emitDebugValues if DBG_VALUEs are removed at<br>
runOnMachineFunction.<br>
<br>
rdar://problem/13183203<br>
Reviewed by Andy & Jakob<br>
<br></blockquote><div><br></div></div><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. Also, it shouldn't depend upon whether or not we're enabling misched or not, a simple testcase should be an unused parameter and dce.</div>
<div class="im">
<div><br></div><span style="color:rgb(34,34,34);font-size:13.333333015441895px;font-family:arial,sans-serif">+define void @Proc8(i32* nocapture %Array1Par, [51 x i32]* nocapture %Array2Par, i32 %IntParI1, i32 %IntParI2) nounwind optsize ssp uwtable {</span><br style="color:rgb(34,34,34);font-size:13.333333015441895px;font-family:arial,sans-serif">

<div><br></div></div><div>You also shouldn't need ssp/uwtable on this.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 class LiveDebugVariables : public MachineFunctionPass {<br>
   void *pImpl;<br>
+  /// Whether emitDebugValues is called.<br>
+  bool EmitDone;<br>
+  /// Whether the machine function is modified during the pass.<br>
+  bool ModifiedMF;<br></blockquote><div><br></div></div><div> Any reason why these aren't going into the pass impl?</div><div><br></div><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? If so, Manman, can you delete the now dead code?</div>

<div><br></div><div>Thanks!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-eric</div></font></span></div>
</blockquote></div><br></div>