Re: compiling very large functions.

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Andrew MacLeod wrote:
> On Sat, 2006-11-04 at 15:17 -0500, Kenneth Zadeck wrote:
>   
>> ld. 
>>     
>
>   
>> However, I think that before anyone starts hacking anything, we should
>> come to a consensus on an overall strategy and implement something
>> consistent for the entire compiler rather than attack some particular
>> pass in a manner that only gets us pass the next pr. 
>>     
>
> I think we really do need to deal with it on a per pass basis. We
> occasionally get a monster PR which shows half a dozen (or more) serious
> time hogs. We more often get a pathological case for a specific pass. 
>
> In each and every one of these cases, someone has taken a look at how to
> improve the time hog(s). Usually the result is a leaner/faster and
> improved pass, although it sometimes takes a new release for it to
> happen :-). Occasionally, we turn something off.   A couple of PRs with
> massive functions are primarily responsible for the pending changes to
> out-of-ssa... And those changes will benefit small functions as well as
> the large ones.  
>
>   
The problem with trying to solve this problem on a per pass basis rather
than coming up with an integrate solution is that we are completely
leaving the user out of the thought process.

There are some uses who have big machines or a lot of time on their
hands and want the damn the torpedoes full speed ahead and there are
some uses that want reasonable decisions made even at high
optimization.  We need to give them any easy to turn knob. 

I am not saying that my original proposal was the best of all possible
worlds, but solving hacking things on a pass by pass or pr by pr basis
is not really solving the problem.

kenny