forward from linux-kernel

[Marc Lehmann <pcg at goof dot com>]

this is a recent post by linus torvalds, in a discussion about
bad long long performance in gcc. (part of linus wishlist):

On Mon, 16 Feb 1998, Alan Cox wrote:                                   
>
> > Sure, the 64-bit version may _look_ simpler to do, but if you actually
> > try to optimize it for performance you'll wish you hadn't gone to "long
> > long". And the page cache is timing critical.                         
>
> 64bits is what folks will expect, and with things like lseek you dont need
> a paticularly huge disk to create file using bit63 in its file offsets. If
> long long is so bad maybe the right answer is to ask the egcs people to
> look into it - and yes Im aware gcc on the whole writes crud code for
> any case where sizeof(register) < sizeof(object). Its what makes gcc
> so weak for embedded work.                   

I'd certainly like to see egcs improve "long long" handling, but I think
that on the x86 the problem is twofold. The long long handling is just    
plain bad, and that's probably the easiest one to fix up with some md file
updates. But the worse problem is probably bad register handling in gcc,
both for normal registers and for "eflags".
For example, a lot of the long long things are really _five_ register      
inputs: two source registers, two source-dest registers, and eflags to
keep track of the carry bit. That means that you have four registers (out
of eight) just for data - something that gcc isn't too good at anyway, but
you also have the added constraint that you must keep the right eflags 
updates: and gcc-x86 doesn't seem to track eflags at all (it has various
"magic" eflags rules, but gcc doesn't actually seem to consider eflags to 
be a real register, so it can't actually schedule any of the code very     
well).                         

Maybe egcs is better at handling eflags on x86, but I'd really like to      
think that we have a stable compiler first, rather than trusting a known    
bad compiler (yes, gcc is actually known for having generated not only   
slow but actually buggy code for "long long").                         

                Linus