This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop unrolling
- To: vonbrand at sleipnir dot valparaiso dot cl
- Subject: Re: Loop unrolling
- From: mrs at wrs dot com (Mike Stump)
- Date: Mon, 15 Jun 1998 17:53:39 -0700
- Cc: amylaar at cygnus dot co dot uk, branko dot cibej at hermes dot si, egcs at cygnus dot com, law at cygnus dot com, pfeifer at dbai dot tuwien dot ac dot at
> Date: Sat, 13 Jun 1998 08:32:30 -0500
> From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
> mrs@wrs.com (Mike Stump) said:
> [...]
> > Well, this wasn't the result of the consersation when last we agreed
> > on what to do and what the doc meant and what the compiler should do.
> > The decision whether or not a loop could be removed was to be decided
> > by the source input tokens to the lexer. Not by the existing rtl
> > codes.
> That is a horribly broken idea.
What you mean to say is that people that expect gcc to correctly
compile old style timing loops are wrong for expecting it to work, and
that you think we should break their existing code, renig on our
documented promise to not break their code, and remove this documented
GNU extension from gcc, and break their code.
Do I have that right?
If so, that is a much better way to phrase it. I won't argue against
it heavily.
That is a fine thing to say, but it is better to express it that way
so that people understand the totality of your statement, otherwise
people that don't know better are led to the mistaken conclusion that
I am just misguided and that you are obviously correct.
> That way you have to get non-standard lexical information down to
> the loop-optimizer.
And?
> The data paths for that surely aren't in place,
They mostly are, but some icky code would have to be added to get the
last ounce of performance out of the optimizer, if one wanted it.