[PATCH] PR/17860: wrong code generated by loop optimizer up to 3.4

[Paolo Bonzini]

 > 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)
     do
       ...
     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.

Paolo