search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Different code generation [csmith generated code] #1 #40081

Open Quuxplusone opened 5 years ago

Quuxplusone commented 5 years ago
Bugzilla Link PR41111
Status NEW
Importance P enhancement
Reported by praveenvelliengiri (praveenvelliengiri@gmail.com)
Reported on 2019-03-17 03:49:52 -0700
Last modified on 2019-09-29 01:47:31 -0700
Version trunk
Hardware PC Linux
CC efriedma@quicinc.com, greg.bedwell@sony.com, jdevlieghere@apple.com, keith.walker@arm.com, llvm-bugs@lists.llvm.org, paul_robinson@playstation.sony.com, praveenvelliengiri@gmail.com, yechunliangcn@163.com
Fixed by commit(s)
Attachments hit2.cpp (72015 bytes, text/x-c++src)
hide1 (34229 bytes, text/x-tex)
hide2 (34227 bytes, text/x-tex)
Blocks PR37728
Blocked by
See also 
Created attachment 21620
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
Quuxplusone commented 5 years ago

Attached hit2.cpp (72015 bytes, text/x-c++src): Random code

Quuxplusone commented 5 years ago

Attached hide1 (34229 bytes, text/x-tex): with di attached

Quuxplusone commented 5 years ago

Attached hide2 (34227 bytes, text/x-tex): without di

Quuxplusone commented 5 years ago

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)

Quuxplusone commented 5 years ago 
> Maybe you can find the pass in question using opt-bisect-limit
> (http://llvm.org/docs/OptBisect.html)

Thank you. I will try that.
Quuxplusone commented 5 years ago 
> 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
Quuxplusone commented 5 years ago 
(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.
Quuxplusone commented 5 years ago 
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.
Quuxplusone commented 5 years ago 
Yeah, I get the point here. I will use creduce and find the reduced source code.
Thanks
Quuxplusone commented 5 years ago 
I could not reproduce this issue by clang version 10.0.0
(https://github.com/llvm/llvm-project.git
9ebed3104629f30f12a1f3e391c767397a89d6a5)