Mail Archives: pgcc/1998/07/20/13:23:40
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 |
|
- Raw text -