<div dir="ltr">We've had a lot of success using cfe/trunk/utils/check_cfc in combination with C-Reduce to find, report and fix -g codegen change bugs (see <a href="http://llvm.org/devmtg/2015-04/slides/Verifying_code_gen_dash_g_final.pdf">http://llvm.org/devmtg/2015-04/slides/Verifying_code_gen_dash_g_final.pdf</a> ). There are definitely a fair few left to go though.  Sadly it's rare that they get near to the top of our priority list to deal with, but it would be nice to get the test suites all running green with check_cfc so that we can more easily quickly spot regressions, so the more people willing to attack it the better I think.<div><br></div><div>-Greg</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 July 2017 at 18:10, John Regehr via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How much of a priority is it to find codegen changes triggered by flags such as -g? As long as the effects are reliable between runs this shoud be really easy to attack using C-Reduce. I can look into it if this is important.<br>
<br>
John<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On 7/6/17 11:12 AM, Robinson, Paul via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Out of curiosity<br>
what kinds of changes arise from the presence/absence of -g? (It's not<br>
just the expected presence/absence of the debug info?)<br>
</blockquote>
<br>
Adding -g does have codegen effects, the most common reason being<br>
that it adds IR instructions, some of which have uses of variables,<br>
and sometimes passes don't ignore those things properly.  I think<br>
all the really egregious cases have been fixed by now (at one point<br>
they were counted in inlining costs, which meant that -g affected<br>
inlining decisions!), but we see it now and again.<br>
<br>
There can also be minor instruction-ordering effects because -g wants<br>
to emit unwind info, which appears in the form of assembler .cfi_*<br>
directives, and those appear to be instruction-ordering barriers.<br>
That's the one that pops to mind as something we haven't tried to fix.<br>
<br>
There might be others, I haven't looked at that stuff lately.<br>
--paulr<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>