[llvm-dev] Uncovering non-determinism in LLVM - The Next Steps

[Greg Bedwell via llvm-dev]

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>