This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs-971031, sparc-sun-solaris2.5 new bootstrap failure
- To: Jim Wilson <wilson at cygnus dot com>
- Subject: Re: egcs-971031, sparc-sun-solaris2.5 new bootstrap failure
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Sat, 8 Nov 97 13:17:31 +0100
- Cc: egcs at cygnus dot com
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <199711072252.OAA17857@cygnus.com>
> Here is a patch to fix this. This will be in the next
> snapshot.
>
> Thu Nov 6 18:27:36 1997 Jim Wilson <wilson@cygnus.com>
>
> * flags.h (flag_rerun_loop_opt): Declare.
> * loop.c (invariant_p, case LABEL_REF): Check
> flag_rerun_loop_opt.
> * toplev.c (flag_rerum_loop_opt): Delete static.
Ah, that means that Jeff implemented rerun-loop-opt slightly
differently from the way g77 had it; we *did* have an externally
visible flag -frerun-loop-opt.
> We don't know the loop bounds here though, so
> just fail for all labels. */
> ! /* ??? This is also necessary if
> flag_rerun_loop_opt is true, because in
> ! this
> case we may be doing loop unrolling the second time we
> run loop,
> ! and hence the first loop run also
> needs this check. There is no way
> ! to check here
> whether the second run will actually do loop unrolling
> ! though, as that info is in a local var in
> rest_of_compilation. */
> ! if (flag_unroll_loops || flag_rerun_loop_opt)
> return 0;
> else
> return 1;
Fascinating - this error must have been in g77 too (between 0.5.18,
April '96 and 0.5.20, March '97). We never found a problem with it
though.
For g77-0.5.20 I decided to have loop unrolling only happening in
the second pass through loop_optimize (as it is in egcs now),
because the backend is not good at optimising unrolled loops. One
can easily check this by compiling the following on a ix86 (for
simplicity this assumes n % 4 == 0):
subroutine daxpy(x, y, a, n)
integer n
double precision x(n), y(n), a
do i = 1, n, 4
y(i ) = y(i ) + a * x(i )
y(i+1) = y(i+1) + a * x(i+1)
y(i+2) = y(i+2) + a * x(i+2)
y(i+3) = y(i+3) + a * x(i+3)
enddo
end
This basically is again pointing out that an optimisation that
combine_givs *should* do isn't done, and we end up using 8 different
pseudo registers for the array accesses.
HTH,
Toon.