Ed Maste via llvm-dev
2017-Jul-06 15:34 UTC
[llvm-dev] Uncovering non-determinism in LLVM - The Next Steps
On 6 July 2017 at 11:02, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Grang, Mandeep Singh wrote: >> I would like to hear the community's thoughts on these proposals.>From the perspective of the recent focused effort on reproduciblebuilds, I think this is excellent.>> We ideally want to compare rel vs >> rel+asserts vs debug with Linux vs Windows toolchains. Any differences >> in objdumps could signal a potential non-determinism. > > You might want to do this part first, partly because you can do it > today with no further patches to LLVM. ... > > My team has done something like your proposal, but comparing with/without > -g and -S. In those cases there are a number of innocuous differences > that we have had to teach our comparison tool to ignore. But we also > found some real bugs and that was very satisfying.It does seem like a good idea to start with comparing output compiled on 32- and 64-bit hosts, or on Windows and Linux. 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?)> There might also be differences across hosts that you just have to live > with.Being able to build identical objects using the same version of Clang built with different host compilers on different operating systems is nice in that it allows use of techniques from diverse double compilation to improve confidence in the toolchain. It would be great to at least know if / how objects currently differ when compiled in cases like this.
Robinson, Paul via llvm-dev
2017-Jul-06 16:12 UTC
[llvm-dev] Uncovering non-determinism in LLVM - The Next Steps
> 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
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 >