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

Sun Nov 11 22:32:06 PST 2018

 >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.

LLVM IR transformations are (in theory) designed to work on any valid 
IR, so any failure of
a single pass on IR that passes validation is either a bug in pass or a 
bug in IR validation.

IF you have a valid IR and it fails on a single pass then the actual 
reason of failure is really
in that particular pass.

And in vast majority of cases it is absolutely inessential how you get 
this IR, as soon as you get
exactly the same failure. It might happen that you find a different bug 
but that could happen
with any reducing procedure and it mostly depends on how you detect "the 
failure".
You know, there could be (or rather there always are!) multiple bugs in 
a single pass! :),
Using a fixed sequence of passes will not protect you from that at all.

regards,
   Fedor.

On 11/12/18 4:58 AM, cszide wrote:
> 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/3a409c15/attachment.html>