[luau] compiler optimization?

[Warren Togami]

On Thu, 2003-05-15 at 14:13, MonMotha wrote:
> Lou Rickard wrote:
> ...
> > 
> > I'm running RH 7.2, with RH's 2.9.6 version of gcc, on
> > a pentium3.
> > 
> 
> 2.9.6 has a reputation for being a POS.  It has been known to miscompile things 
> (quite often in fact).  It's possible that optmizations were basically disabled 
> along the way in an attempt to combat this.
> 

All cases of miscompilation that I have seen have been either been
refuted as wrong, or were valid bugs fixed in later versions of 2.96. 
Indeed gcc 2.96 was completely unreliable as released in early Red Hat
7.x series.  By 7.2 or 7.3 it was usable though.

Anyhow, the argument is moot considering that 2.96 is obsolete, 3.2.x
being the standard used by all now.

> Needless to say, compiler optimizations on gcc 3.2 (I haven't gotten a chance to 
> toy with 3.3 yet) can do some rather impressiev things.  Changing from -O2 to 
> -Os generally shaves about 25k off my kernel's bzImage (that's AFTER 
> compression) and can make about a 10k difference in the size of my busybox 
> images.  This doesn't sound like much, but my kernels tend to be rather small 
> (about 600-950k) and busybox pretty much maxes at 300-350k.  Another great way 
> to really save some size is to use -fomit-frame-pointer.  Unfortunately this can 
> make debugging a rather large pain.
> 
> In terms of speed, it can make a noticable difference to increase the 
> optmization level, especially if you manually invoke some of the more dangerous 
> options.  Of course, as you pump the optimization level up or invoke more and 
> more optimizations explicitly, the higher the chance you'll find a compiler 
> "bug", or simply an optmization that a creatively written piece of code just 
> doesn't like.
> 
> --MonMotha