<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:nikita.ppv@gmail.com" title="Nikita Popov <nikita.ppv@gmail.com>"> <span class="fn">Nikita Popov</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - opt -enable-new-pm=0 -loop-deletion fails with Assertion `!isInvalid() && "Loop not in a valid state!"' failed."
href="https://bugs.llvm.org/show_bug.cgi?id=49967">bug 49967</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>nikita.ppv@gmail.com
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - opt -enable-new-pm=0 -loop-deletion fails with Assertion `!isInvalid() && "Loop not in a valid state!"' failed."
href="https://bugs.llvm.org/show_bug.cgi?id=49967#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - opt -enable-new-pm=0 -loop-deletion fails with Assertion `!isInvalid() && "Loop not in a valid state!"' failed."
href="https://bugs.llvm.org/show_bug.cgi?id=49967">bug 49967</a>
from <span class="vcard"><a class="email" href="mailto:nikita.ppv@gmail.com" title="Nikita Popov <nikita.ppv@gmail.com>"> <span class="fn">Nikita Popov</span></a>
</span></b>
<pre>I've added the test case in
<a href="https://github.com/llvm/llvm-project/commit/6e8e165085d4506d3df15da79f70abe1237a26ba">https://github.com/llvm/llvm-project/commit/6e8e165085d4506d3df15da79f70abe1237a26ba</a>.
Here's a trace of what happens in this case:
Fetching: %inc89 = add nuw nsw i16 %i58.010, 1
Fetching: i16 1
Reused: 1
Fetching: i16 1
Reused: 1
Fetching: %i58.010 = phi i16 [ 32, %vector.ph ], [ %inc89, %for.body63 ]
Reused: {32,+,1}<nuw><nsw><%for.body63>
Created: {33,+,1}<nuw><nsw><%for.body63>
Fetching: i16 33
Reused: 33
B Invalidating: %i58.010 = phi i16 [ 32, %vector.ph ], [ %inc89, %for.body63
] - {32,+,1}<nuw><nsw><%for.body63>
B Invalidating: %inc89 = add nuw nsw i16 %i58.010, 1 -
{33,+,1}<nuw><nsw><%for.body63>
B Skipping: %i58.010 = phi i16 [ 32, %vector.ph ], [ %inc89, %for.body63 ]
B Skipping: %exitcond12.not = icmp eq i16 %inc89, 33
B Skipping: br i1 %exitcond12.not, label %for.cond.cleanup62, label
%for.body63
Created: {33,+,1}<nuw><nsw><%for.body63>
getBackedgeTakenInfo() will invalidate values in the loop when it first
computes BE counts. In this case, this happens while computing the SCEV for the
post-inc addrec. As a result, the post-inc addrec will be cached, without the
pre-inc addrec (corresponding to the loop header phi) being cached.
This goes against the basic assumption of my patch, that the loop header phi
will always have a cached value if there is a cached expression based on it.
I'll have to find some other way to solve my original motivation.</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>