This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CSE not combining equivalent expressions.


On Thu, 2007-01-18 at 12:44 +0530, pranav bhandarkar wrote:
> On 1/17/07, Mircea Namolaru <NAMOLARU@il.ibm.com> wrote:
> > > Thanks. Another question I have is that, in this case, will the
> > following
> > >
> > > http://gcc.gnu.org/wiki/Sign_Extension_Removal
> > >
> > > help in removal of the sign / zero extension ?
> >
> > First, it seems to me that in your case:
> >
> > (1) a = a | 1 /* a |= 1 */
> > (2) a = a | 1 /* a |= 1 */
> >
> > the expressions "a | 1" in (1) and (2) are different as the "a"
> > is not the same. So there is nothing to do for CSE.
> >
> > If the architecture has an instruction that does both the
> > store and the zero extension, the zero extension instructions
> > become redundant.
> >
> > The sign extension algorithm is supposed to catch such cases, but
> > I suspect that in this simple case the regular combine is enough.
> >
> > Mircea
> >
> Thanks for the info. I went through the documentation provided by you
> in see.c, which I must add is very comprehensive indeed, and realised
> that we need an instruction that does a zero extend before a store so
> that that the extension instructions become redundant and can be
> removed.
I haven't followed this thread that closely, but it seems to me this
could be done in the propagation engine.

Basically we keep track of the known zero, sign bit copies and known 
nonzero bits for SSA names, then propagate them in the obvious ways.
Basically replicating a lot of what combine & cse do in this area,
but at the tree level.   It's something I've always wanted to see
implemented, but never bothered to do...

jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]