<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Non-deterministic behavior when using LoopInfo pass in LLVM"
href="http://llvm.org/bugs/show_bug.cgi?id=17714">17714</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Non-deterministic behavior when using LoopInfo pass in LLVM
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>raphaelernani@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=11435" name="attach_11435" title="My test pass and Oscar.linked.rbc, extracted from the LLVM test suite (Singlesource/Benchmarks/Stanford)">attachment 11435</a> <a href="attachment.cgi?id=11435&action=edit" title="My test pass and Oscar.linked.rbc, extracted from the LLVM test suite (Singlesource/Benchmarks/Stanford)">[details]</a></span>
My test pass and Oscar.linked.rbc, extracted from the LLVM test suite
(Singlesource/Benchmarks/Stanford)
Hello,
I'm having a little problem with passes that use LoopInfo. Their statistics
aren't the same when I execute the same pass multiple times in the same
program.
After some investigation, I've found out that LoopInfo is the root of the
problem.
I wrote a little pass that counts the loop headers (number of basic blocks for
which LoopInfo.isLoopHeader(BB) is true). I've picked one of the programs in
the LLVM test suite benchmarks and in three consecutive tests the number of
loop headers was different.
I've sent this problem in the LLVM-dev mailing list and it seems that this
behavior is wrong. Please check this out.
I'm sending attached the bitcodes used in my tests and my little pass.
Thanks,
Raphael Ernani
P.S.: Here is the output (a similar variation occurs when I run my pass without
-mem2reg, -instnamer, and -break-crit-edges):
raphael@ubuntu:~/llvm-3.3/projects/test-suite/SingleSource/Benchmarks/Stanford/Output$
opt -mem2reg -instnamer -break-crit-edges -load MyModule.so -lh-counter -stats
Oscar.linked.rbc -f >/dev/null
===-------------------------------------------------------------------------===
... Statistics Collected ...
===-------------------------------------------------------------------------===
12 NaturalLoopAnalysis - Number of Loop Headers
8 break-crit-edges - Number of blocks inserted
23 mem2reg - Number of PHI nodes inserted
38 mem2reg - Number of alloca's promoted
20 mem2reg - Number of alloca's promoted with a single store
raphael@ubuntu:~/llvm-3.3/projects/test-suite/SingleSource/Benchmarks/Stanford/Output$
opt -mem2reg -instnamer -break-crit-edges -load MyModule.so -lh-counter -stats
Oscar.linked.rbc -f >/dev/null
===-------------------------------------------------------------------------===
... Statistics Collected ...
===-------------------------------------------------------------------------===
13 NaturalLoopAnalysis - Number of Loop Headers
8 break-crit-edges - Number of blocks inserted
23 mem2reg - Number of PHI nodes inserted
38 mem2reg - Number of alloca's promoted
20 mem2reg - Number of alloca's promoted with a single store
raphael@ubuntu:~/llvm-3.3/projects/test-suite/SingleSource/Benchmarks/Stanford/Output$
opt -mem2reg -instnamer -break-crit-edges -load MyModule.so -lh-counter -stats
Oscar.linked.rbc -f >/dev/null
===-------------------------------------------------------------------------===
... Statistics Collected ...
===-------------------------------------------------------------------------===
11 NaturalLoopAnalysis - Number of Loop Headers
8 break-crit-edges - Number of blocks inserted
23 mem2reg - Number of PHI nodes inserted
38 mem2reg - Number of alloca's promoted
20 mem2reg - Number of alloca's promoted with a single store</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>