This is the mail archive of the
mailing list for the GCC project.
gcc port to StarCore
- From: "David Livshin" <dlivshin at internet-zahav dot net>
- To: <gcc at gcc dot gnu dot org>
- Date: Wed, 1 May 2002 15:23:31 +0200
- Subject: gcc port to StarCore
I am working on the port of the gcc version 3.0.1 to the StarCore
architecture ( DSP from Motorola/Agere ). The compiler works fine and
produces correct StarCore code that passes all the validations ( I have ).
However there are cases where it can do better job:
1. no constant propagation:
compiling with '-O3'
x = 10;
y = 100;
if ( x > y )
generates code to actually compare 'x' and 'y' disregarding the fact that
comparison always produces the same result.
This is not done in other versions of gcc, so what may be wrong in my
implementation that prevents compiler from performing necessary
optimizations? I don't think this problem relates to implementation of
integer comparison, as e.g.
x = 10;
y = 100;
z = y/x;
generates code to perform the division.
2. loop handling
my port generates weird an unoptimal code for loops. The body of the loop is
often has jumps to it ( as in the example below ) and consist of the
disjoint blocks that are spread over the generated code. The best looking
loop I seen gcc generates is for the code ( compiled with -O3 ):
for ( i = 0; i < 100; i++ )
sum += i;
The jump "bra __L_L__8" is not necessary ( may be this relates to the first
problem I described ) but even if it is necessary to determine if loop is
executed, what may prevent gcc from doing it before entering the body of the
loop ( like it is done in other implementations of gcc )?
In addition to disallowing many loop optimizations ( e.g. motion of the loop
invariant "moveu.l #99,d1" that sets the register "d1' to 99, out of loop ),
it seems that such a structure of a loop prevents the compiler to utilize
"decrement_and_branch_until_zero" and "doloop_begin/end" found in the md
Thank you in advance,
Tel: +972 - 8 - 935 - 4597
Mobile: +972 - 67 - 290 - 998