Re: GCSE store motion

[Mark Mitchell <mark at codesourcery dot com>]

--On Thursday, May 16, 2002 07:48:38 AM -0400 Robert Dewar <dewar@gnat.com> 
wrote:

>> That means we shouldn't be spending much time trying to do software
>> loop pipelining when compiling GCC, so the optimization shouldn't
>> make compiling the compiler significantly slower.
>
> I don't see how you conclude this. You have to do the analysis on every
> loop. There will definitely be loops in GCC where the optimization is
> possible, there will be loops where it is not. I would expect the
> compiler to spend quite a bit of time trying to improve code for
> loops in GCC. What I am saying is that I doubt that the overall
> effect will be that benficial for GCC.

I think we're wandering into a good pub conversation, rather than a useful
debate about criteria for accepting changes in the compiler, but...

There aren't very many loops in GCC; certainly nowhere near as many (per
line of code) as in your average scientific application, say.  And, a
little heuristicness (most of these loops have lots of internal branches
and even function calls, therefore they're less liikely to be hot spots,
therefore I won't spend a lot of effor trying to wring a few cycles out
of them), doesn't seem unreasonable to me.

I picked a random GCC file (regmove.c) and counted 127 lines with the
word "for", 8 with "while", and 54 with "do" out of 73694 lines.  (That's
probably an over-estimate; I'd bet some of those show up in comments.)

How much time can/should the compiler waste compiling those relatively
few loops?

My point is that I can well imagine the compiler spending 10% of its time
on software pipelining for scientific code, but that would seem highly
out of whack on code like that in GCC.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com