On 12/03/2015 02:36 AM, Richard Biener wrote:
On Wed, Dec 2, 2015 at 5:27 PM, Jeff Law <l...@redhat.com> wrote:
I strongly recommend reading the analysis in pr45122 since pr68599 uses the
same testcase and just triggers the same bug in the RTL optimizers instead
of the tree optimziers.
As noted in 45122, with -funsafe-loop-optimizations, we may exit the loop an
iteration too early. The loop in question is finite and the counter does
not overflow. Yet -funsafe-loop-optimizations munges it badly.
As is noted in c#6 and patched in c#8, when there's more than one exit from
the loop, simply discarding the assumptions for the trip count is "a bit too
unsafe". Richi & Zdenek agreed that disabling the optimization when the
loop has > 1 exit was the preferred approach. Alex's patch did just that,
but only for the tree optimizers.
This patch does essentially the same thing for the RTL loop optimizer. If
the candidate loop has > 1 exit, then we don't allow
-funsafe-loop-optimizations to drop the assumptions/infinite notes for the
RTL loop.
This required ensuring that LOOPS_HAVE_RECORDED_EXITS when initializing the
loop optimizer.
Bootstrapped and regression tested on x86_64-linux-gnu and
powerpc64-linux-gnu. For the latter, pr45122.c flips to a pass. Given this
is covered by the pr45122 testcase, I didn't add a new one.
OK for the trunk?
Ok.
Note that I believe we should dump -funsafe-loop-optimizations in
favor of a per-loop
#pragma now that we can properly track such. Globally it's known to miscompile
SPEC at least.
Yea, I saw that on IRC and almost went down that path. Certainly
wouldn't get any argument from me if we were to remove that option.
Sounds like Bin might want to do that and he'll have my full support.
Jeff
