GCC assmbler for powerpc-eabi

GCC assmbler for powerpc-eabi

[marian Szczepkowski]

We are looking at GCC and another compiler for use on an embedded
powerpc project and in comparing the two compilers I get this,

From GCC
	lis 9,pstr@ha
	lwz 0,pstr@l(9)
	mr 3,0
	crxor 6,6,6
	bl atoi
	mr 29,3

From vendor
172		lwz	r3, 532(r31)
173		bl	atof
174		bl	_d_dtof
175		stw	r3, 12(sp)


GCC appears to be doing some extra work here and I am at a loss to work
out what it is doing this for, why the crxor 6,6,6 from my reading this
is the floating point exception in the CR, and GCC does this every time,
as here...

	lwz 3,8(31)
	lis 9,.LC1@ha
	la 4,.LC1@l(9)
	mr 5,29
	mr 6,0
	crxor 6,6,6
	bl sprintf

Can some one explain this seemingly irrelevant extra step..

Re: GCC assmbler for powerpc-eabi

[Andrew Haley]

marian Szczepkowski wrote:
> We are looking at GCC and another compiler for use on an embedded
> powerpc project and in comparing the two compilers I get this,
> 
>From GCC
> 	lis 9,pstr@ha
> 	lwz 0,pstr@l(9)
> 	mr 3,0
> 	crxor 6,6,6
> 	bl atoi
> 	mr 29,3
> 
>From vendor
> 172		lwz	r3, 532(r31)
> 173		bl	atof
> 174		bl	_d_dtof
> 175		stw	r3, 12(sp)
> 
> 
> GCC appears to be doing some extra work here and I am at a loss to work
> out what it is doing this for, why the crxor 6,6,6 from my reading this
> is the floating point exception in the CR, and GCC does this every time,
> as here...
> 
> 	lwz 3,8(31)
> 	lis 9,.LC1@ha
> 	la 4,.LC1@l(9)
> 	mr 5,29
> 	mr 6,0
> 	crxor 6,6,6
> 	bl sprintf
> 
> Can some one explain this seemingly irrelevant extra step..

Can you supply a small test case that generates this code?

Andrew.

Re: GCC assmbler for powerpc-eabi

[marian Szczepkowski]

Sure, this is what I have as a test as I wanted to look at function call
overhead, and the compiler used is "powerpc-eabi-gcc (eCosCentric GNU
tools 4.3.2-sw) 4.3.2", after a bunch of messing around I ended up using
this to invike the compiler, not that it seemed to make any difference,
"powerpc-eabi-gcc -S println.c  -finline-functions -fbtr-bb-exclusive
-fdefer-pop -fwhole-progr". I lay no claim to brilliance with compiler
options I was primarily just trying to see if the options had any
effect.


#define unsigned int size_t


#include <stdio.h>

char *pstr ="42";

void myCall(char *cptr)
{
	sprintf(cptr,"Hello baby %f %u", atoi(pstr),atof(pstr));
}

void main(int argc, char **argv)
{
	char cptr[32];
	myCall(&cptr[0]);
	printf("%s\n",cptr);
}
/* END */


On Sun, 2009-04-05 at 21:45 +0100, Andrew Haley wrote:
> marian Szczepkowski wrote:
> > We are looking at GCC and another compiler for use on an embedded
> > powerpc project and in comparing the two compilers I get this,
> > 
> >>From GCC
> > 	lis 9,pstr@ha
> > 	lwz 0,pstr@l(9)
> > 	mr 3,0
> > 	crxor 6,6,6
> > 	bl atoi
> > 	mr 29,3
> > 
> >>From vendor
> > 172		lwz	r3, 532(r31)
> > 173		bl	atof
> > 174		bl	_d_dtof
> > 175		stw	r3, 12(sp)
> > 
> > 
> > GCC appears to be doing some extra work here and I am at a loss to work
> > out what it is doing this for, why the crxor 6,6,6 from my reading this
> > is the floating point exception in the CR, and GCC does this every time,
> > as here...
> > 
> > 	lwz 3,8(31)
> > 	lis 9,.LC1@ha
> > 	la 4,.LC1@l(9)
> > 	mr 5,29
> > 	mr 6,0
> > 	crxor 6,6,6
> > 	bl sprintf
> > 
> > Can some one explain this seemingly irrelevant extra step..
> 
> Can you supply a small test case that generates this code?
> 
> Andrew.

Re: GCC assmbler for powerpc-eabi

[Jeff Chimene]

On 04/05/2009 05:20 PM, marian Szczepkowski wrote:
> Sure, this is what I have as a test as I wanted to look at function call
> overhead, and the compiler used is "powerpc-eabi-gcc (eCosCentric GNU
> tools 4.3.2-sw) 4.3.2", after a bunch of messing around I ended up using
> this to invike the compiler, not that it seemed to make any difference,
> "powerpc-eabi-gcc -S println.c  -finline-functions -fbtr-bb-exclusive
> -fdefer-pop -fwhole-progr". I lay no claim to brilliance with compiler
> options I was primarily just trying to see if the options had any
> effect.
>
>    
I tried this on my box.

A few notes:
o The compiler barfed until I swapped the #define and the #include
o The -finline-functions switch has no effect until one specifies the 
-O3 switch. From TFM:

`-finline-functions'
      Integrate all simple functions into their callers.  The compiler
      heuristically decides which functions are simple enough to be worth
      integrating in this way.

      If all calls to a given function are integrated, and the function
      is declared `static', then the function is normally not output as
      assembler code in its own right.

      Enabled at level `-O3'.

> #define unsigned int size_t
>
>
> #include<stdio.h>
>
> char *pstr ="42";
>
> void myCall(char *cptr)
> {
> 	sprintf(cptr,"Hello baby %f %u", atoi(pstr),atof(pstr));
> }
>
> void main(int argc, char **argv)
> {
> 	char cptr[32];
> 	myCall(&cptr[0]);
> 	printf("%s\n",cptr);
> }
> /* END */
>    

SSA vs RTL

[charfi asma]

Hello every body,

I am a newbie in GCC, and I am intersested in GCC optimization
I can not find a simple example that explain why Constant propagation is more efficient in SSA form than in RTL form ?
I knew that in SSA form, the algorithm is faster. but why ?
Can so give me an example that explain why RTL do it slower ?

thank you very much

Asma

Re: SSA vs RTL

[Ian Lance Taylor]

charfi asma <charfiasma@yahoo.fr> writes:

> I am a newbie in GCC, and I am intersested in GCC optimization
> I can not find a simple example that explain why Constant propagation is more efficient in SSA form than in RTL form ?
> I knew that in SSA form, the algorithm is faster. but why ?
> Can so give me an example that explain why RTL do it slower ?

Please do not ask a new question by replying to a message on the mailing
list.  Instead, send a new message.  When you reply to a message, it
shows up in the wrong place for people using threaded e-mail readers.

Your question is really one about compiler theory, not one about gcc.
Constant propagation is faster when using SSA simply because each
variable is set only once, which means that you can very easily
determine whether a variable has a constant value.  In RTL form each
pseudo-register can be set multiple times, so for each use of a
pseudo-register you have to determine the set of values which the
pseudo-register may hold at that time.

Ian

Re: GCC assmbler for powerpc-eabi

[John (Eljay) Love-Jensen]

Hi Jeff,

> o The compiler barfed until I swapped the #define and the #include

As it should, since that #define is really weird and will break most header
files and most code.

(I¹m not sure why you want to replace ³unsigned² with ³int size_t².)

> o The -finline-functions switch has no effect until one specifies the -O3
switch.

The -finline-functions switch is enabled by default with -O3.

You can enable it manually at -O1 or -O2.

HTH,
--Eljay

Re: GCC assmbler for powerpc-eabi

[Jeff Chimene]

On 04/06/2009 10:35 AM, John (Eljay) Love-Jensen wrote:
> Hi Jeff,
>
>    
Hi Eljay,

Thanks for the updates!

Please note that I was responding to Marian Szczepkowski
>> o The compiler barfed until I swapped the #define and the #include
>>      
>
> As it should, since that #define is really weird and will break most header
> files and most code.
>
> (I�m not sure why you want to replace �unsigned� with �int size_t�.)
>    
Dunno - that's how I found the code sample...
>    
>> o The -finline-functions switch has no effect until one specifies the -O3
>>      
> switch.
>
> The -finline-functions switch is enabled by default with -O3.
>
> You can enable it manually at -O1 or -O2.
>    

Agreed. Please note that the command line as posted by Marian contained 
no -O* switch...

Cheers,
jec

Re: GCC assmbler for powerpc-eabi

[marian]

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

Ok I seem to have caused some consternation here, the code is not
intended to do anything meaningful, it is part of the assessment as to
whether GCC/GDB is a valid replacement for our current tool set. It's
role is to get assembler so we cam verify function call overhead as part
of the initial static analysis of each tool used. Unfortunately I picked
sprintf as a test library call and it appears that this causes the
compiler to emit the crxor even when no math is being performed. 

ref. PowerPC Microprocessor 32-bit Family: The Programming Environments
sec. 2.1.3.2 Condition Register CR1 Field Definition
pp.  2-6

ref. PowerPC 405-S Embedded Processor Core
sec. 2.3.4 Condition Register

The 405 ref seems to conflict, or seems to define a usage that is less
specific than the general reference.

The question is still, why do I have the crxor assembler statements
before every "bl sprintf" statement in the function? 

Files are attached and the build was done from inside ecos/test..

So fixing my compile line so it doesn't barf, 
../gnutools/powerpc-eabi/bin/powerpc-eabi-gcc -S -O2 println.c
-I./ecos_install/include/

I get a build result of 

println.c: In function ‘myCall’:
println.c:11: warning: incompatible implicit declaration of built-in
function ‘sprintf’
println.c: In function ‘myCall2’:
println.c:15: warning: incompatible implicit declaration of built-in
function ‘sprintf’
println.c: In function ‘main’:
println.c:23: warning: incompatible implicit declaration of built-in
function ‘printf’

which gives me an assembler function which still has 

myCall2:
	mflr 0
	stwu 1,-8(1)
	lis 9,pstr@ha
	lis 4,.LC0@ha
	la 4,.LC0@l(4)
	stw 0,12(1)
	lwz 5,pstr@l(9)
	crxor 6,6,6	<<<< WHY <<<<<<
	bl sprintf
	lwz 0,12(1)
	addi 1,1,8
	mtlr 0
	blr



On Mon, 2009-04-06 at 10:35 -0700, John (Eljay) Love-Jensen wrote:
> Hi Jeff,
> 
> > o The compiler barfed until I swapped the #define and the #include
> 
> As it should, since that #define is really weird and will break most header
> files and most code.
> 
> (I¹m not sure why you want to replace ³unsigned² with ³int size_t².)
> 
> > o The -finline-functions switch has no effect until one specifies the -O3
> switch.
> 
> The -finline-functions switch is enabled by default with -O3.
> 
> You can enable it manually at -O1 or -O2.
> 
> HTH,
> --Eljay
> 

[-- Attachment #2: println.c --]
[-- Type: text/x-csrc, Size: 404 bytes --]




#include <stdio.h>
#include <string.h>

char *pstr ="42";
char *blowup=NULL;

void myCall(char *cptr)
{
	sprintf(cptr,"Hello baby %f %u", atoi(pstr),atof(pstr));
	memcpy(blowup,pstr,strlen(pstr));
}
void myCall2(char *cptr)
{
	sprintf(cptr,"Hello baby %s", pstr);
}

int main(int argc, char **argv)
{
	char cptr[32];
	myCall(&cptr[0]);
	myCall2(&cptr[0]);
	printf("%s\n",cptr);
	return 0;
}
/* END */

[-- Attachment #3: println.s --]
[-- Type: text/plain, Size: 1654 bytes --]

	.file	"println.c"
	.gnu_attribute 4, 1
	.gnu_attribute 8, 1
	.section	".text"
	.align 2
	.globl myCall2
	.type	myCall2, @function
myCall2:
	mflr 0
	stwu 1,-8(1)
	lis 9,pstr@ha
	lis 4,.LC0@ha
	la 4,.LC0@l(4)
	stw 0,12(1)
	lwz 5,pstr@l(9)
	crxor 6,6,6
	bl sprintf
	lwz 0,12(1)
	addi 1,1,8
	mtlr 0
	blr
	.size	myCall2, .-myCall2
	.align 2
	.globl myCall
	.type	myCall, @function
myCall:
	stwu 1,-32(1)
	mflr 0
	stw 29,20(1)
	lis 29,pstr@ha
	stw 27,12(1)
	mr 27,3
	lwz 3,pstr@l(29)
	stw 0,36(1)
	stw 28,16(1)
	crxor 6,6,6
	bl atoi
	mr 28,3
	lwz 3,pstr@l(29)
	crxor 6,6,6
	bl atof
	lis 4,.LC1@ha
	mr 6,3
	mr 5,28
	la 4,.LC1@l(4)
	mr 3,27
	crxor 6,6,6
	bl sprintf
	lwz 28,pstr@l(29)
	mr 3,28
	bl strlen
	lis 9,blowup@ha
	mr 5,3
	lwz 3,blowup@l(9)
	mr 4,28
	bl memcpy
	lwz 0,36(1)
	lwz 27,12(1)
	mtlr 0
	lwz 28,16(1)
	lwz 29,20(1)
	addi 1,1,32
	blr
	.size	myCall, .-myCall
	.globl __eabi
	.align 2
	.globl main
	.type	main, @function
main:
	stwu 1,-56(1)
	mflr 0
	stw 29,44(1)
	addi 29,1,8
	stw 0,60(1)
	bl __eabi
	mr 3,29
	bl myCall
	lis 9,pstr@ha
	lwz 5,pstr@l(9)
	lis 4,.LC0@ha
	la 4,.LC0@l(4)
	mr 3,29
	crxor 6,6,6
	bl sprintf
	mr 3,29
	bl puts
	lwz 0,60(1)
	li 3,0
	lwz 29,44(1)
	mtlr 0
	addi 1,1,56
	blr
	.size	main, .-main
	.globl pstr
	.globl blowup
	.section	.rodata.str1.4,"aMS",@progbits,1
	.align 2
.LC0:
	.string	"Hello baby %s"
	.zero	2
.LC1:
	.string	"Hello baby %f %u"
	.zero	3
.LC2:
	.string	"42"
	.section	.sbss,"aw",@nobits
	.align 2
	.type	blowup, @object
	.size	blowup, 4
blowup:
	.zero	4
	.section	.sdata,"aw",@progbits
	.align 2
	.type	pstr, @object
	.size	pstr, 4
pstr:
	.long	.LC2
	.ident	"GCC: (eCosCentric GNU tools 4.3.2-sw) 4.3.2"

Re: GCC assmbler for powerpc-eabi

[Ian Lance Taylor]

marian <marian@jozep.com.au> writes:

> 	crxor 6,6,6	<<<< WHY <<<<<<
> 	bl sprintf

The various PPC ABIs are unreasonably complicated.  The crxor
instruction is required by some of them.  It is used when calling a
function which takes a variable number of arguments.  crxor is used to
indicate that no floating point arguments were passed.  creqv is used to
indicate that at least one floating point argument was passed.  The
varargs function checks the condition register to see whether it has to
push the floating point parameter registers on the stack in order to let
va_arg work correctly.

Since most varargs functions do not have any floating point arguments,
it is usually a good tradeoff to have one exact instruction in the
caller to save several memory operations in the callee.

If you prefer a different tradeoff, you can fool with the -mcall-XXX
options.

Ian