This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR/17860: wrong code generated by loop optimizer up to3.4

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]