Open Quuxplusone opened 5 years ago
Attached hit2.cpp
(72015 bytes, text/x-c++src): Random code
Attached hide1
(34229 bytes, text/x-tex): with di attached
Attached hide2
(34227 bytes, text/x-tex): 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)
hit2.cpp
(72015 bytes, text/x-c++src)hide1
(34229 bytes, text/x-tex)hide2
(34227 bytes, text/x-tex)