[new-ra] GCC-3.3.2/x86: some suspicious behaviour

[new-ra] GCC-3.3.2/x86: some suspicious behaviour

[Denis Zaitsev]

This source


extern inline
void *i(void *d, void *s, int n)
{
    __asm__ __volatile__ ( ""
        :"+&c"(n), "+&D"(d), "+&S"(s)
    );
}
void *o(void *d, void *s, int n)
{
    return i(d, s, n);
}


is compiled into that assembler:


o:
	pushl	%edi
	pushl	%esi
	movl	12(%esp), %edi
	movl	16(%esp), %esi
	movl	20(%esp), %ecx
	popl	%esi
	popl	%edi
	ret


Everything looks ok.  But the source modified slightly


extern inline
void *i(void *d, void *s, int n)
{
    __asm__ __volatile__ ( ""
        :"+&c"(n), "+&D"(d), "+&S"(s)
    );
    __asm__ __volatile__ ( ""
        :"+&c"(n), "+&D"(d), "+&S"(s)
    );
}
void *o(void *d, void *s, int n)
{
    return i(d, s, n);
}


is compiled into that assembler:


o:
	pushl	%edi
	pushl	%esi
	movl	12(%esp), %edi
	movl	20(%esp), %ecx
	movl	16(%esp), %esi
	movl	%ecx, 16(%esp)
	movl	%esi, 20(%esp)
	popl	%esi
	popl	%edi
	ret


So, what does these two commands mean:


	movl	%ecx, 16(%esp)
	movl	%esi, 20(%esp)


?  The options for the compiler are:


-O2 -fomit-frame-pointer -fnew-ra


The result is the same for any -O >0 and for -Os.  And the presence of
these suspicious commands are not affected by the frame-pointer
option.

Re: [new-ra] GCC-3.3.2/x86: some suspicious behaviour

[Michael Matz]

Hi,

On Thu, 8 Jul 2004, Denis Zaitsev wrote:

> So, what does these two commands mean:
> 
> 
> 	movl	%ecx, 16(%esp)
> 	movl	%esi, 20(%esp)

It means that the compiler wasn't able to optimize them away.  They do no 
harm.  FWIW gcc 3.4 or the new-regalloc-branch don't have this problem.

> The result is the same for any -O >0 and for -Os.  And the presence of
> these suspicious commands are not affected by the frame-pointer option.


Ciao,
Michael.

Re: [new-ra] GCC-3.3.2/x86: some suspicious behaviour

[Denis Zaitsev]

On Thu, Jul 08, 2004 at 04:46:33PM +0200, Michael Matz wrote:
> Hi,
> 
> On Thu, 8 Jul 2004, Denis Zaitsev wrote:
> 
> > So, what does these two commands mean:
> > 
> > 
> > 	movl	%ecx, 16(%esp)
> > 	movl	%esi, 20(%esp)
> 
> It means that the compiler wasn't able to optimize them away.  They do no 
> harm.  FWIW gcc 3.4 or the new-regalloc-branch don't have this problem.

They don't harm.  But to optimize _what_?  So, what is the initial
meaning of these assignments?  And why they appear only for the double
asm statement?

Re: [new-ra] GCC-3.3.2/x86: some suspicious behaviour

[Paul Brook]

On Thursday 08 July 2004 17:31, Denis Zaitsev wrote:
> On Thu, Jul 08, 2004 at 04:46:33PM +0200, Michael Matz wrote:
> > Hi,
> >
> > On Thu, 8 Jul 2004, Denis Zaitsev wrote:
> > > So, what does these two commands mean:
> > >
> > >
> > > 	movl	%ecx, 16(%esp)
> > > 	movl	%esi, 20(%esp)
> >
> > It means that the compiler wasn't able to optimize them away.  They do no
> > harm.  FWIW gcc 3.4 or the new-regalloc-branch don't have this problem.
>
> They don't harm.  But to optimize _what_?  So, what is the initial
> meaning of these assignments?  And why they appear only for the double
> asm statement?

They're storing the modified values of s and d back into their stack slots 
after the first asm. The compiler wasn't able to determine that these were 
dead stores.

Remove the "extern inline" and compile with -O0. This will show you 
approximately what the code looks like before optimization.

Paul

Re: [new-ra] GCC-3.3.2/x86: some suspicious behaviour

[Denis Zaitsev]

On Thu, Jul 08, 2004 at 05:52:57PM +0100, Paul Brook wrote:
> On Thursday 08 July 2004 17:31, Denis Zaitsev wrote:
> > On Thu, Jul 08, 2004 at 04:46:33PM +0200, Michael Matz wrote:
> > > Hi,
> > >
> > > On Thu, 8 Jul 2004, Denis Zaitsev wrote:
> > > > So, what does these two commands mean:
> > > >
> > > >
> > > > 	movl	%ecx, 16(%esp)
> > > > 	movl	%esi, 20(%esp)
> > >
> > > It means that the compiler wasn't able to optimize them away.  They do no
> > > harm.  FWIW gcc 3.4 or the new-regalloc-branch don't have this problem.
> >
> > They don't harm.  But to optimize _what_?  So, what is the initial
> > meaning of these assignments?  And why they appear only for the double
> > asm statement?
> 
> They're storing the modified values of s and d back into their stack slots 
> after the first asm. The compiler wasn't able to determine that these were 
> dead stores.
> 
> Remove the "extern inline" and compile with -O0. This will show you 
> approximately what the code looks like before optimization.

Yes, this way the variables are really just stored back into their
stack locations.  But in my case:


	movl	20(%esp), %ecx
	movl	16(%esp), %esi
	movl	%ecx, 16(%esp)
	movl	%esi, 20(%esp)


So, the stack slots seem to be swapped.  Why?