This is the mail archive of the 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: [PATCH] Fix PR15791, 2nd try

On Thu, 27 Jan 2005, Andrew Pinski wrote:

> On Jan 27, 2005, at 12:08 PM, Richard Guenther wrote:
> > Second try - this time it works for even more weird cases.
> > Also maybe all comments have been addressed.
> >
> > Another round of testing is in work.
> >
> > Richard.
> I think you still can get a type mismatch.
> Take the following code (compile with the C++ front-end):
> int f(int i, unsigned j)
> {
>    int t = i>j?i:j;
>    int b[2];
>    return &b[i] == &b[j];
> }
> you will see &b[i] == &b[j] and no casts so you end up with a
> comparision
> between an unsigned and int without a NOP_EXPR which is wrong.

That doesn't seem to be the case - I'll get no folding and

    int t;
    int b[2];

    i.0 = (unsigned int) i;
    D.1568 = MAX_EXPR <j, i.0>;
    t = (int) D.1568;
    i.1 = i;
    D.1571 = &b[i.1];
    j.2 = j;
    D.1573 = &b[j.2];
    D.1569 = D.1571 == D.1573;
    return D.1569;

but it seems the C++ frontend doesn't try to fold something
like &b[i] == &b[j] directly.

But you are potentially right here - is there some more strict

> Also you should try to deal with the following also:
> int f(int i, unsigned j)
> {
>    int t = i>j?i:j;
>    int b[2][2];
>    return &b[1][i] == &b[1][j];
> }
> Which you get: ADDR_EXPR<ARRAY_REF<ARRAY_REF <b, 1>,i> > but you might
> be able to handle
> it, I don't know.

I don't do any folding here - that'd require me to recurse somehow
and deal with multiple indices.  It would be better if we consistently
lowered all the address arithmetic to a canonical form for such
optimizations anyway.  F.i. the C and C++ frontends seem to emit
different initial trees for the same purpose and/or call fold in
different order on these trees.

> Also add testcases to gcc to the testsuite to make sure that you are
> doing this
> optimization correctly and is being done.

Yes, that's a good idea.  But rather than looking for "good" optimization
I'm curious wether I might do something wrong, of course.  After all,
this is my first fiddling with optimization of trees.


Richard Guenther <richard dot guenther at uni-tuebingen dot de>

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