X-pop3-spooler: POP3MAIL 2.1.0 b 4 980420 -bs-
Message-ID: <19980720000547.11808@cerebro.laendle>
Date: Mon, 20 Jul 1998 00:05:47 +0200
From: Marc Lehmann <pcg AT goof DOT com>
To: Vincent Diepeveen <diep AT xs4all DOT nl>
Cc: beastium <beastium-list AT Desk DOT nl>
Subject: Re: PGCC's optimizations (continued)
Mail-Followup-To: Vincent Diepeveen <diep AT xs4all DOT nl>,
	beastium <beastium-list AT desk DOT nl>
References: <3 DOT 0 DOT 32 DOT 19980718015819 DOT 00994ca0 AT xs4all DOT nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <3.0.32.19980718015819.00994ca0@xs4all.nl>; from Vincent Diepeveen on Sat, Jul 18, 1998 at 02:00:15AM +0100
X-Operating-System: Linux version 2.1.109 (root AT cerebro) (gcc version pgcc-2.91.50 19980714 (gcc2 ss-980609 experimental)) 
Status: RO
Content-Length: 3338
Lines: 99

On Sat, Jul 18, 1998 at 02:00:15AM +0100, Vincent Diepeveen wrote:
> 
> I have arrays like 
>   unsigned char movetables[1..a][1..b],*sq;
>   int u;
> 
> And i use then in a while loop:
>   sq = movetables[something];
>   // now the problem is that this sq must be before i use it converted to
>   // an int. 
>   while( (u = (int)*sq) != c ) { 
>     // now i'm using u in all kind of lookups    
>     sq += bla bla;
>   }  

(this is an example of an unnecessary cast, btw:

  u = (int)*sq

the expression "*sq", when evaluated as an rvalue, has type "int" (or
unsigned int in case an unsigned char doesn't fit into an int))
> 
>   Now the main problem is this conversion from *sq goes to u.
>   
> ALL compilers suck in this respect. they all lack some simple optimization
> rules for lusses and casting.

actually, its not the cast but the integer promotion here, and egcs generates:

        movzbl (%edx),%eax

which should be optimal...

> They all either do for example              XOR eax,eax
> and then move the variable in the register: mov  al,...

not egcs (I believe gcc-2.8 will do the same). It seems you tested with
_pentium_ optimizations (on pentiums, xor+mov is way faster than movzbl). IF
you try with pentiumpro optimizations, a good compiler will definitely
generate movzbl (as will bad compilers on all architectures)

> Then in the 486 age the only wrong optimization was the extra XORs needed,
> because you only need to do 1 XOR and OUTSIDE the loop, and not inside
> the loop.

This is true (and also almost impossible to represent in gcc), but not much
of the problem for pii&ppro&k6, as these are fast with the mov[sz][bw][wl]
instructions.

> so i get punished for using 8 bits datastructure, and no way to prevent it.

sure there is ;)

> The only way to prevent it is using assembler and also rewriting the
> variables to 8 bits. The compilers do only 32 bits datamanipulation so they

but thats also what I would expect when you work with ints? If you work with
chars, most compilers will optimize these to 8 bit operations.

> another main problem is handling the if then else in the while loop

I'm not sure what you mean (what are lus/lusses??). this example:

extern int board[];
volatile int i;
int sq;

int f() {
   while(i) {
      if (board [sq] == 15) {
         volatile int k=0xcode1;
      } else if (board[sq] == 2) {
         volatile int k=0xcode2;
      }
   }
}

> So the only 2 references are to the board[sq] in an if then else construction.

compiles exactly to the code below. Can you give a more complate example
that I can actually test?

> These are quite simple. I have bunches of those cases left...
> ....and also quite some more difficult if you like.

Go on, lets see.. ;

> If all those things would be in 1 compiler then it would speed my
> chessprogram up considerably.

well, we're close, although egcs does have big problems with loops.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg AT goof DOT com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |