From: Toon Moene <toon@moene.indiv.nluug.nl>
To: Jim Wilson <wilson@cygnus.com>
Cc: egcs@cygnus.com
Subject: Re: egcs-971031, sparc-sun-solaris2.5 new bootstrap failure
Date: Sat, 08 Nov 1997 05:13:00 -0000 [thread overview]
Message-ID: <9711081217.AA08778@moene.indiv.nluug.nl> (raw)
In-Reply-To: <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.
next prev parent reply other threads:[~1997-11-08 5:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-11-07 12:55 Kaveh R. Ghazi
1997-11-07 14:52 ` Jim Wilson
1997-11-08 5:13 ` Toon Moene [this message]
1997-11-09 0:42 ` Jeffrey A Law
1997-11-09 9:20 ` Joern Rennecke
1997-11-09 10:46 ` Jeffrey A Law
1997-11-25 22:49 ` Joern Rennecke
1997-12-06 7:50 ` Jeffrey A Law
1997-11-09 7:52 ` Toon Moene
-- strict thread matches above, loose matches on Subject: below --
1997-11-08 20:45 Kaveh R. Ghazi
1997-11-03 9:43 Kaveh R. Ghazi
1997-11-03 17:55 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9711081217.AA08778@moene.indiv.nluug.nl \
--to=toon@moene.indiv.nluug.nl \
--cc=egcs@cygnus.com \
--cc=wilson@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).