This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR/17860: wrong code generated by loop optimizer up to3.4
- From: Paolo Bonzini <paolo dot bonzini at polimi dot it>
- To: Dave Korn <dave dot korn at artimi dot com>
- Cc: Paolo Bonzini <bonzini at gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, gcc at gcc dot gnu dot org
- Date: Tue, 12 Oct 2004 14:25:01 +0200
- Subject: Re: [PATCH] PR/17860: wrong code generated by loop optimizer up to3.4
- References: <28D25EB5A34E89408B73B6793C7421711C99@nutmeg.CAM.ARTIMI.COM>
> 2) Does it actually matter directly that the VTOPs don't match?
> AFAICS the test (set (reg:CCGC 17 flags) ...) at the LOOP_BEG (insn
> 61) is dead, isn't it, since there's nothing in straight-line between
> it and the clobber (reg:CC 17 flags) at insn 28. The code in the dbra
> optimisation that you've patched out doesn't check for anything else
> except the existence of a vtop; if the two tests still matched, would
> it still be wrong?
No. But it is relying on vtop's to deduce a property of a loop (being a
while loop rather than do...while), and the testcase shows how this
property may not be true anymore after CSE. Uses of vtop like the one I
removed need to be either fixed or removed; and I suspect that *all of
the uses of vtop* need to.
Basically, I think that removing a not-very-often-used transformation in
an almost dead optimization pass is feasible. Remember 3.4 has Zdenek's
dominator-based loop optimizer as well.
> But the invalid note remains in the generated rtl, yes? And so it
> might perhaps - but in these testcases doesn't - cause a problem in one
> of these four later places you list ? [...]
> I'm not familiar with the loop optimisers, so forgive me if some of my
> questions seem dumb, but I'm curious about the implications of these
> uses. Are you fairly confident that simply removing the code that emits
> the VTOP notes will just cause a few optimisation opportunities to be
> lost but is unlikely to lead to misbehaviour in these places?
It definitely won't. VTOP notes are only extra information, they are
used to gather properties of the instructions between them and END. If
you write all your loops like this,
if (--x > 0)
while (--x > 0);
voila, no more VTOP notes, because the only place they are created is
during loop header copying. Besides, mainline has not had them since
the tree-ssa merge (and they have been completely removed last August).
So removing them can only give pessimization (and less bugs), leaving
them in can only give more optimization (and more bugs).
> And those last two cases that you mention in unroll.c, if we're just
> trying to find the loop iteration count, wouldn't it be possible to
> determine the information from the LOOP_BEG instead of the VTOP? They
> both seem like they ought to be quite simple cases to recognize,
> shouldn't they?
It seems like other parts of the optimizer make this less than trivial
(very much so), while VTOP notes make it easier. But they are
intrinsically brittle, it seems to me.