John Regehr via llvm-dev
2017-Jul-06 17:10 UTC
[llvm-dev] Uncovering non-determinism in LLVM - The Next Steps
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. John On 7/6/17 11:12 AM, Robinson, Paul via llvm-dev wrote:>> Out of curiosity >> what kinds of changes arise from the presence/absence of -g? (It's not >> just the expected presence/absence of the debug info?) > > Adding -g does have codegen effects, the most common reason being > that it adds IR instructions, some of which have uses of variables, > and sometimes passes don't ignore those things properly. I think > all the really egregious cases have been fixed by now (at one point > they were counted in inlining costs, which meant that -g affected > inlining decisions!), but we see it now and again. > > There can also be minor instruction-ordering effects because -g wants > to emit unwind info, which appears in the form of assembler .cfi_* > directives, and those appear to be instruction-ordering barriers. > That's the one that pops to mind as something we haven't tried to fix. > > There might be others, I haven't looked at that stuff lately. > --paulr > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Greg Bedwell via llvm-dev
2017-Jul-06 17:20 UTC
[llvm-dev] Uncovering non-determinism in LLVM - The Next Steps
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 http://llvm.org/devmtg/2015-04/slides/Verifying_code_gen_dash_g_final.pdf ). 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. -Greg On 6 July 2017 at 18:10, John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote:> 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. > > John > > > > > On 7/6/17 11:12 AM, Robinson, Paul via llvm-dev wrote: > >> Out of curiosity >>> what kinds of changes arise from the presence/absence of -g? (It's not >>> just the expected presence/absence of the debug info?) >>> >> >> Adding -g does have codegen effects, the most common reason being >> that it adds IR instructions, some of which have uses of variables, >> and sometimes passes don't ignore those things properly. I think >> all the really egregious cases have been fixed by now (at one point >> they were counted in inlining costs, which meant that -g affected >> inlining decisions!), but we see it now and again. >> >> There can also be minor instruction-ordering effects because -g wants >> to emit unwind info, which appears in the form of assembler .cfi_* >> directives, and those appear to be instruction-ordering barriers. >> That's the one that pops to mind as something we haven't tried to fix. >> >> There might be others, I haven't looked at that stuff lately. >> --paulr >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/5a88834a/attachment.html>
John Regehr via llvm-dev
2017-Jul-06 17:29 UTC
[llvm-dev] Uncovering non-determinism in LLVM - The Next Steps
> (see http://llvm.org/devmtg/2015-04/slides/Verifying_code_gen_dash_g_final.pdfSuper cool, I had missed this. I hope to be doing some more LLVM testing work soonish and will keep this tool on the list. John