Created attachment 21620 [details] Random code Hi The source file attached produce different codegen behaviour for X86_64 at optimization levels -O2, -O3, -Os with -g enabled and disabled. Interesting note here is that disassembly of code at one -opt level vary a lot from code generated at different -opt level. I have attached the source file, code generated at -O2 with/without -g option. Steps to reproduced in X86_64 linux. clang++ -c -g -O2 -Wno-everything -I/headers/of/csmith source.cpp -o di clang++ -c -O2 -Wno-everything -I/headers/of/csmith source.cpp -o nodi objdump -d -j .text nodi > hide1 objdump -d -j .text di > hide2 colordiff hide1 hide2 || diff hide1 hide2 As these are randomly generated, the reducing to these to minimum test case is quite difficult. I'm working on that. Anyone have thoughts on it? Please reply Thanks
Created attachment 21621 [details] with di attached
Created attachment 21622 [details] without di
> As these are randomly generated, the reducing to these to minimum test case is quite difficult. Maybe you can find the pass in question using opt-bisect-limit (http://llvm.org/docs/OptBisect.html)
> Maybe you can find the pass in question using opt-bisect-limit > (http://llvm.org/docs/OptBisect.html) Thank you. I will try that.
> Maybe you can find the pass in question using opt-bisect-limit > (http://llvm.org/docs/OptBisect.html) I tried optbisect tool, but i still can't able to find the pass which causes bad codegen. Is this the way people normally find bad codegen errors? Thanks
(In reply to praveenvelliengiri from comment #0) > As these are randomly generated, the reducing to these to minimum test case > is quite difficult. I'm working on that. > This should reduce quite nicely using c-reduce. https://embed.cs.utah.edu/creduce/ Just make sure that your test1.sh returns 0 if there is a difference in codegen when -g is specified, and 1 if there is no difference. I'd recommend getting a reduced source level case as your first step. Using -opt-bisect-limit may be tricky though. Typically you'd just add "-mllvm -opt-bisect-limit=99999" to your clang options which would give you a load of output like this on stderr: ~~~~~ <snip initial lines> BISECT: running pass (111) X86 Execution Dependency Fix on function (main) BISECT: running pass (112) BreakFalseDeps on function (main) BISECT: running pass (113) X86 Byte/Word Instruction Fixup on function (main) BISECT: running pass (114) X86 Atom pad short functions on function (main) BISECT: running pass (115) X86 LEA Fixup on function (main) $ ~~~~~ So you know that, in the case of the example I had sitting around, there were 115 passes run at -O2 so you could just reduce the limit from 115 downwards until you observe a relevant difference in behaviour. What complicated things here is that -g appears to actually make a difference in the number of passes that are run. In my case 115 vs 118 where the difference is the following passes that get run with -g. BISECT: running pass (47) Remove unused exception handling info on SCC (llvm.dbg.value) BISECT: running pass (48) Function Integration/Inlining on SCC (llvm.dbg.value) BISECT: running pass (49) Deduce function attributes on SCC (llvm.dbg.value) It might be complicated to try to compensate for these differences.
llvm.dbg.* instrinsics probably shouldn't be part of the callgraph... maybe worth fixing. Using CReduce first is probably a good idea if you can get it to work.
Yeah, I get the point here. I will use creduce and find the reduced source code. Thanks
I could not reproduce this issue by clang version 10.0.0 (https://github.com/llvm/llvm-project.git 9ebed3104629f30f12a1f3e391c767397a89d6a5)