[llvm-dev] Are there any tools to reduce the IR file that caused a problem?

[cszide via llvm-dev]

Hi Fedor,
Thanks for your suggestions! I will try it.
I agree with you that "in many cases the problem is indeed in a single pass, so finding exact 
pass is rather beneficial." Actually, in my case, bugpoint also shows that only one pass will 
cause the problem, but I can only know the wrong instructions in the "bugpoint-reduced-simplified.bc" 
file rather than the original "a.bc" file. 
For example, in my test case,  the "loop-deletion" pass will cause a problem for "bugpoint-reduced-simplified.bc". 
The output of opt (in debug mode) is:
"
While deleting: i32* %
Use still stuck around after Def is destroyed:  %161 = load i32, i32* <badref>, align 4, !tbaa !1
....
Stack dump:
0.Program arguments: /Documents/llvm/llvm6.0/llvm-6.0.0.src/build/bin/opt 
bugpoint-reduced-simplified.bc -loop-deletion -disable-output 
1.Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.bc'.
2.Running pass 'Loop Pass Manager' on function '@put2bitbwtile'
3.Running pass 'Delete dead loops' on basic block '<badref>'
Aborted (core dumped)
"
Next, I use llvm-dis to disassemble "bugpoint-reduced-simplified.bc", and I found that the 
resulted "bugpoint-reduced-simplified.ll" file only contains two load instructions, i.e., 
"
....
%241 = load i32*, i32** undef, align 8, !tbaa !1
....
%248 = load i32, i32* %241, align 4, !tbaa !5
....
"
but from "bugpoint-reduced-simplified.ll", it is difficult to know why there is a "i32** undef" .
"bugpoint-reduced-simplified.bc" is reduced from the IR that has been optimized by some passes, 
thus it is hard to know the actual reasons.
For my test case, only a few passes sequences that contain "loop-deletion" pass have this problem.
In most cases, the passes sequences is good. So I think the problem is caused by interaction among passes 
that why I want to know the wrong passes sequences and to reduce the original IR file.


Best regards,
Zhide







At 2018-11-11 21:24:16, "Fedor Sergeev via llvm-dev" <llvm-dev at lists.llvm.org> wrote:
>In many cases the problem is indeed in a single pass, so finding exact 
>pass is rather beneficial.
>
>If you *really* want to stick to a particular sequence of passes you can 
>feed bugpoint with a custom script
>that takes IR and does what you need.
>The tricky part is how to control bugpoint, since sometimes it behaves 
>somewhat unobvious.
>I usually use exit code 134, which for bugpoint means crash:
>
>] cat bugpoint-custom-simple.sh
>opt -do-what-you-want-here "$@"  ; run something else if needed
>[[ problem reproduced ]] && echo "Problem reproduces!" && exit 134
>exit 0
>] bugpoint -compile-custom -compile-command=./bugpoint-custom-check.sh 
>bad.ll
>
>regards,
>   Fedor.
>
>On 11/11/18 9:56 AM, cszide via llvm-dev wrote:
>> Hi everyone,
>> I want to test the passes in llvm, and I got some passes sequences 
>> that caused the crash of opt.
>> Although I can use bugpoint to narrow down the source of problems, I 
>> can only get some reduced and
>> simplified IR and passes to reproduce the problem. My question is how 
>> to get the reduced IR of the original IR
>> file to reproduce the problem. For example,
>> "opt a.bc -a -b -c -d (where a, b, c and d are passes)" has a crash 
>> problem caused by "-a -b -c -d", so we can use
>> bugpoint to narrow down the source of problems, thus bugpoint will 
>> tell us "You can reproduce the problem with:
>> opt bugpoint-reduced-simplified.bc -c". However, for the 
>> "bugpoint-reduced-simplified.bc", I do not know the actual wrong points
>> of the original "a.bc", and the pass "-c" is good for "a.bc", the 
>> actual wrong passes sequence is "-b -c" for "a.bc", i.e., we need to 
>> run pass "-b" before
>> pass "-c" to reproduce the problem on the original IR file.
>> So how to reduce the original IR and get the actual wrong passes 
>> sequence? Are there any tools? Or there are some special tips of bugpoint
>> for this purpose?
>>
>>
>>
>> _______________________________________________
>> 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/20181112/151b62f3/attachment.html>