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?
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.
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* , 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
- Running pass ‘Function Pass Manager’ on module ‘bugpoint-reduced-simplified.bc’.
- Running pass ‘Loop Pass Manager’ on function ‘@put2bitbwtile’
- Running pass ‘Delete dead loops’ on basic block ‘’
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
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.