<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
>but from "bugpoint-reduced-simplified.ll", it is difficult to
know why there is a "i32** undef" .
<div>> "bugpoint-reduced-simplified.bc" is reduced from the IR
that has been optimized by some passes, </div>
<div>> thus it is hard to know the actual reasons.<br>
<br>
LLVM IR transformations are (in theory) designed to work on any
valid IR, so any failure of<br>
a single pass on IR that passes validation is either a bug in pass
or a bug in IR validation.<br>
<br>
IF you have a valid IR and it fails on a single pass then the
actual reason of failure is really<br>
in that particular pass.<br>
<br>
And in vast majority of cases it is absolutely inessential how you
get this IR, as soon as you get<br>
exactly the same failure. It might happen that you find a
different bug but that could happen<br>
with any reducing procedure and it mostly depends on how you
detect "the failure".<br>
You know, there could be (or rather there always are!) multiple
bugs in a single pass! :),<br>
Using a fixed sequence of passes will not protect you from that at
all.<br>
<br>
regards,<br>
Fedor.<br>
<br>
<br>
</div>
<div class="moz-cite-prefix">On 11/12/18 4:58 AM, cszide wrote:<br>
</div>
<blockquote type="cite"
cite="mid:94f2587.3bf4.16705a48946.Coremail.cszide@163.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div
style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial">
<div>Hi Fedor,</div>
<div>Thanks for your suggestions! I will try it.</div>
<div>I agree with you that "in many cases the problem is indeed
in a single pass, so finding exact </div>
<div>pass is rather beneficial." Actually, in my case, bugpoint
also shows that only one pass will </div>
<div>cause the problem, but I can only know the wrong
instructions in the "bugpoint-reduced-simplified.bc" </div>
<div>file rather than the original "a.bc" file. </div>
<div>For example, in my test case, the "loop-deletion" pass
will cause a problem for "bugpoint-reduced-simplified.bc". </div>
<div>The output of opt (in debug mode) is:</div>
<div>"</div>
<div>
<div>While deleting: i32* %</div>
<div>Use still stuck around after Def is destroyed: %161 =
load i32, i32* <badref>, align 4, !tbaa !1</div>
</div>
<div>....</div>
<div>
<div>Stack dump:</div>
<div>0.<span style="white-space:pre"> </span>Program
arguments:
/Documents/llvm/llvm6.0/llvm-6.0.0.src/build/bin/opt </div>
<div>bugpoint-reduced-simplified.bc -loop-deletion
-disable-output </div>
<div>1.<span style="white-space:pre"> </span>Running pass
'Function Pass Manager' on module
'bugpoint-reduced-simplified.bc'.</div>
<div>2.<span style="white-space:pre"> </span>Running pass
'Loop Pass Manager' on function '@put2bitbwtile'</div>
<div>3.<span style="white-space:pre"> </span>Running pass
'Delete dead loops' on basic block '<badref>'</div>
<div>Aborted (core dumped)</div>
</div>
<div>"</div>
<div>Next, I use llvm-dis to disassemble
"bugpoint-reduced-simplified.bc", and I found that the </div>
<div>resulted "bugpoint-reduced-simplified.ll" file only
contains two load instructions, i.e., </div>
<div>"</div>
<div>....</div>
<div>%241 = load i32*, i32** undef, align 8, !tbaa !1</div>
<div>....</div>
<div>%248 = load i32, i32* %241, align 4, !tbaa !5</div>
<div>....</div>
<div>"</div>
<div>but from "bugpoint-reduced-simplified.ll", it is difficult
to know why there is a "i32** undef" .</div>
<div>"bugpoint-reduced-simplified.bc" is reduced from the IR
that has been optimized by some passes, </div>
<div>thus it is hard to know the actual reasons.</div>
<div>For my test case, only a few passes sequences that contain
"loop-deletion" pass have this problem.</div>
<div>In most cases, the passes sequences is good. So I think the
problem is caused by interaction among passes </div>
<div>that why I want to know the wrong passes sequences and to
reduce the original IR file.</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Zhide</div>
<br>
<br>
<br>
<br>
<pre>
At 2018-11-11 21:24:16, "Fedor Sergeev via llvm-dev" <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a> 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
>> <a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
>> <a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
>
>_______________________________________________
>LLVM Developers mailing list
><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
><a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</div>
<br>
<br>
<span title="neteasefooter">
<p> </p>
</span>
</blockquote>
<br>
</body>
</html>