[PR target/20126, RFC] loop DEST_ADDR biv replacement may fail

[Alexandre Oliva]

On Apr 12, 2005, Roger Sayle <roger@eyesopen.com> wrote:

> I still like your fallbacks, that by trying harder we perform better
> optimization,

The more I think about this, the more I have the impression that
perhaps the fallbacks are not necessary.  My gut feeling (that has
been wrong before, so take that with a grain of salt) is that, if we
mark the giv as ignored, its assignment within the loop won't be
removed (if they ever are, I'm not entirely sure), so if we introduce
a new assignment, we're wasting cpu cycles either in the compiler, if
it has to remove the redundant set, or at run-time, if it can't figure
that out.

My feeling stems from the fact that we've never had (AFAIK) a
situation in which the failure to make the change caused a
miscompilation, except in the case of a biv whose final assignment was
hoisted before the loop.  I can't quite figure out why this would ever
make sense; it appears to me that computing its final value after the
loop is always profitable is always better because it would reduce
register pressure, but I may be way off here.  In the two other cases
that were exposed by attempts to report failures in the substitution
(namely, the Ada bootstrap error that Jakub reported against an
earlier version of the patch, and the arm-elf build failure that Josh
reported), the value was there, and, since the code actually refrained
from checking the result of validate_change, perhaps it really didn't
matter whether the substitution worked.  At least until we started
swimming bivs to before the loop...

So I'm wondering if taking out all of the workarounds and going back
to something like what is now in the 4.0 branch, except for the use of
validate_change_maybe_volatile, wouldn't get us exactly what we want.

Unfortunately, cases in which the substitution fails are quite rare,
and the loop code isn't exactly trivial, so it's hard to decide
whether we've just been lucky, or the code was already mostly correct.

Anyhow, in the meantime, could I check in the patch to fix Josh's
asm-elf build failure?  I haven't been able to bootstrap the tree
lately because of PR21029, but I know it would bootstrap successfully
on amd64-linux-gnu (it would never hit the point that I changed :-),
and I know it fixes the arm-elf problem.

It would be nice to keep the hard failure in place for a bit longer,
such that we stood a better chance of finding other situations that
might require work arounds.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}