<div dir="ltr">I'm not necessarily against reverting r128471 and the restricting patch on it, or identifying cases when we might like to more accurately model line info in debug metadata.<div><br></div><div style>I'm curious what you're trying to do with using line number information to identify loop latches. Can you provide a bit of background on what you're trying to do? It might make it easier to identify things that will help.</div>
<div style><br></div><div style>Thanks!</div><div style><br></div><div style>-eric</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 25, 2013 at 4:15 AM, Tim Besard <span dir="ltr"><<a href="mailto:tim.besard@elis.ugent.be" target="_blank">tim.besard@elis.ugent.be</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Since revisions 128471 and 128513 (March 2011) Clang does not emit debug<br>
information for unconditional branches anymore, for example when<br>
branching from the end of an else{} to the continuation block<br>
(CodeGen/CGStmt.cpp line 459 in r177848). Why exactly is this?<br>
<br>
I'm running into this because I'm identifying loop latches based on<br>
their lexical scope. Normally, loop latches always have debug metadata<br>
attached to them. However, in some cases -simplifycfg can merge the loop<br>
latch with a branch which has no debug metadata attached to it (due to<br>
aforementioned reason) causing the final latch not to have debug<br>
metadata either.<br>
<br>
Specifically, I have this testcase:<br>
  while (while_test()) {<br>
    if (if_test()) {<br>
      foo();<br>
    } else {<br>
      bar();<br>
    }<br>
  }<br>
<br>
Clang emits the following bytecode for this:<br>
  while.cond:<br>
    %call = call zeroext i1 (...)* @while_test(), !dbg !9<br>
    br i1 %call, label %while.body, label %while.end, !dbg !9<br>
  while.body:<br>
    %call1 = call zeroext i1 (...)* @if_test(), !dbg !10<br>
    br i1 %call1, label %if.then, label %if.else, !dbg !10<br>
  if.then:<br>
    call void (...)* @foo(), !dbg !12<br>
    br label %if.end, !dbg !14<br>
  if.else:<br>
    call void (...)* @bar(), !dbg !15<br>
    br label %if.end<br>
  if.end:<br>
    br label %while.cond, !dbg !17<br>
  while.end:<br>
    ret i32 0, !dbg !18<br>
Note that the unconditional branch at the end of if.else does not have<br>
debug metadata attached to it.<br>
<br>
When running -simplifycfg, LLVM merges if.else and if.end as follows:<br>
  if.else:<br>
    call void (...)* @bar(), !dbg !15<br>
    br label %while.cond<br>
<br>
The end result of all this is that the loop latch does not have any<br>
metadata attached to it, not only breaking my loop identification, but<br>
presumable also making it impossible to stop at the end of the while<br>
body (something which was possible before running -simplifycfg).<br>
<br>
How should this be fixed? Should -simplifycfg have support for<br>
'properly' merging these statements, or should Clang emit debug<br>
statements despite the branch being unconditional?<br>
<br>
Sincerely,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Tim Besard<br>
Computer Systems Lab<br>
Department of Electronics & Information Systems<br>
Ghent University<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</font></span></blockquote></div><br></div>