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] improve C++ code by changing fold-const.c

On May 27, 2004, at 11:39, Roger Sayle wrote:

On Wed, 26 May 2004, Andrew Pinski wrote:
Okay, I am going to look at a different way.

Hi Andrew,

I'm sorry that I've not found much time to help you with this.
However all six of your proposed patches are variations on folding
NOP_EXPR (t1, ADDR_EXPR (t2, ...)) into ADDR_EXPR (t1, ...).  As
you know fold already handles the case where t1 == t2, so I suspect
a better place to tackle this problem is elsewhere.

Yes right above where I was adding my addition.

The pointer types (const int*), (int&) and (int*) really are all
distinct types, that need to be preserved by the middle-end.  The
thing that makes them all equivalent is that dereferencing them
all returns the same type, "int" [not that we can fool the "fold"
int believing they're really all the same].

Yes but does the idea behind the fold-const is to remove trees which
are extraneous and clean up after the front-ends a little. Building
the tree and folding should be two different distinct parts of gcc
(and in my mind are). Folding (int&)ADDR_EXPR<int*,a> into ADDR_EXPR<int&,a>
should be applicable no matter what correct as the front-end should have
already diagnose the problem if there was one.

Folding NOP_EXPR<const int*, ADDR_EXPR<int*, a>> into ADDR_EXPR<const int*, a>
should be no different than NOP_EXPR<const int, a> into just a, right?

Fold should not be called by the front-end until it knows that the trees
are correct and that it is not going to diagnose any more problems with
subtrees. (I think this is already done but defining this formally will
always be better than having an ad-hoc interface in the sense the
front-end assumes it can call fold even before it diagnose the problems
on the subtrees).  So the idea of fold becomes a different idea from
before when we converted directly from trees to RTL in each front-end.

I suspect that the optimization that you're trying to perform shouldn't
be in the NOP_EXPR part of fold, but in the INDIRECT_REF or COMPONENT_REF
sections of fold.

Why the types change, this is the same argument that you are giving in the
case against my patch, which is why I do not understand you can accept it
here but not in my patch.

i.e. INDIRECT_REF (NOP_EXPR (ADDR_EXPR (X))) => X much like we might
(should?) currently handle INDIRECT_REF (ADDR_EXPR (X)) => X. Or even
more generally, INDIRECT_REF (NOP_EXPR (Y)) => INDIRECT_REF (Y) if the
types are compatible, as investigated/explored by your patch variations.

I have done the later but it does not help at all at least at this point.

Andrew Pinski

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