Threading the compiler

[Mike Stump]

On Nov 10, 2006, at 2:19 PM, Kevin Handy wrote:
> What will the multi-core compiler design do to the old processors  
> (extreme slowness?)

Roughly speaking, I want it to add around 1000 extra instructions per  
function compiled, in other words, nothing.  The compile speed will  
be what the compile speed is.  Now, I will caution, the world doesn't  
look kindly on people trying to bootstrap gcc on a 8 MHz m68k  
anymore, even though it might even be possible.  In 5 years, I'm  
gonna be compiling on an 80 or 160 way box.  :-)  Yeah, Intel  
promised.  If you're trying to compile on a single 1 GHz CPU, it's  
gonna be slow....  I don't want to make the compiler any slower, I  
want to make it faster, others will make use of the faster compiler,  
to make it slower, but that is orthogonal to my wanting to make it  
faster.

> 4. Will you "serialize" error messages so that two compiles of a  
> file will always display the errors in the same order?

Yes, I think that messages should feed back into manager, so that the  
manager can `manage' things.  A stable, rational ordering for  
messages makes sense.

> Also, will the object  files created be the same between compiles.

Around here, we predicate life on determinism, you can pry that away  
from my cold dead fingers.  We might have to switch from L472 to  
L10.22 for internal labels for example.  This way, each thread can  
create infinite amounts of labels that don't conflict with other  
threads (functions).

> 5. Will more "heavy" optimizations be available? i.e. Will the  
> multi-core
>  speed things up enough that really hard optimizations (speed wise)
>  become reasonable?

See my first paragraph.