Redundant instructions in loop optimization for x86-64?

Redundant instructions in loop optimization for x86-64?

[H. J. Lu]

It seems that gcc 3.4 and 4.0 generate redundant instructions in loop
optimization for x86-64:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387

Does anyone know why?


H.J.

Re: Redundant instructions in loop optimization for x86-64?

[Jan Hubicka]

> It seems that gcc 3.4 and 4.0 generate redundant instructions in loop
> optimization for x86-64:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
> 
> Does anyone know why?

It is a zero extension GCC believe to be essential.

Honza
> 
> 
> H.J.

Re: Redundant instructions in loop optimization for x86-64?

[H. J. Lu]

On Fri, Sep 10, 2004 at 11:50:23AM +0200, Jan Hubicka wrote:
> > It seems that gcc 3.4 and 4.0 generate redundant instructions in loop
> > optimization for x86-64:
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
> > 
> > Does anyone know why?
> 
> It is a zero extension GCC believe to be essential.

Is there a way to tell gcc that 32bit zero extension isn't needed for
x86-64?


H.J.

Re: Redundant instructions in loop optimization for x86-64?

[James E Wilson]

H. J. Lu wrote:
> Is there a way to tell gcc that 32bit zero extension isn't needed for
> x86-64?

It isn't quite that simple.  Sometimes they will be needed.  Sometimes 
they won't.

You might want to look at
     http://gcc.gnu.org/ml/gcc/2004-09/msg00377.html
which is a proposal to add an RTL optimization pass to eliminate 
unnecessary sign/zero extension instructions on targets that support 
both 32-bit and 64-bit code.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Redundant instructions in loop optimization for x86-64?

[H. J. Lu]

On Fri, Sep 10, 2004 at 01:43:09PM -0700, James E Wilson wrote:
> H. J. Lu wrote:
> >Is there a way to tell gcc that 32bit zero extension isn't needed for
> >x86-64?
> 
> It isn't quite that simple.  Sometimes they will be needed.  Sometimes 
> they won't.
> 
> You might want to look at
>     http://gcc.gnu.org/ml/gcc/2004-09/msg00377.html
> which is a proposal to add an RTL optimization pass to eliminate 
> unnecessary sign/zero extension instructions on targets that support 
> both 32-bit and 64-bit code.

Is there a version which will apply to the current source tree?


H.J.

Re: Redundant instructions in loop optimization for x86-64?

[James E Wilson]

On Fri, 2004-09-10 at 15:07, H. J. Lu wrote:
> Is there a version which will apply to the current source tree?

I have no idea.  Try asking the authors of the patch.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Redundant instructions in loop optimization for x86-64?

[Jan Hubicka]

> H. J. Lu wrote:
> >Is there a way to tell gcc that 32bit zero extension isn't needed for
> >x86-64?
> 
> It isn't quite that simple.  Sometimes they will be needed.  Sometimes 
> they won't.
> 
> You might want to look at
>     http://gcc.gnu.org/ml/gcc/2004-09/msg00377.html
> which is a proposal to add an RTL optimization pass to eliminate 
> unnecessary sign/zero extension instructions on targets that support 
> both 32-bit and 64-bit code.

Actually I think Zdenek's ivopts should care this case by promoting the
induction variable to 64bit.  I already assigned the bugreport to him,
so lets see what happens son ;)
Without the actual promote, the zero extend is really needed and it is
almost impossible to elliminate it on RTL level since you need to watch
overflows.

Honza
> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Redundant instructions in loop optimization for x86-64?

[Jan Hubicka]

> On Fri, Sep 10, 2004 at 11:50:23AM +0200, Jan Hubicka wrote:
> > > It seems that gcc 3.4 and 4.0 generate redundant instructions in loop
> > > optimization for x86-64:
> > > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
> > > 
> > > Does anyone know why?
> > 
> > It is a zero extension GCC believe to be essential.
> 
> Is there a way to tell gcc that 32bit zero extension isn't needed for
> x86-64?

GCC partly knows about this via combine pattern (ie if the computation
of the value is directly preceeding 32bit operation, it should get these
combined as there are combine patterns for it.

In this case GCC thinkgs that both zero extended and not-zero extended
values are needed (one for addressing, other for next iteration) and
thus combine won't try it.
Of course this is just stupid as both values can live in the same
registers - if we had pass noticing this and converting the later use
into subreg, we would get this optimized out.
Perhaps the pass to elliminate more extension posted somewhere can take
care of this.
> 
> 
> H.J.