This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
- From: Jason Merrill <jason at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Richard Henderson <rth at redhat dot com>,Per Bothner <per at bothner dot com>, Diego Novillo <dnovillo at redhat dot com>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>
- Date: Sun, 21 Jul 2002 23:01:49 +0100
- Subject: Re: Language-independent functions-as-trees representation
- References: <21910000.1027285094@warlock.codesourcery.com>
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
> My disagreement with Per is closer to the front end; I would really
> like the internal representation produced from C++ semantic analysis
> to look like C++ -- with various implicit things made explict (like
> default arguments, choice of overloaded function, choice of template
> specialization, action to take on cleanup of object, etc.)
I don't have a problem with this, except that it makes lowering more
complicated.
> In SIMPLE, one place where I would like the statement/expression to come
> in to play is the following:
> If two expressions are "the same", i.e., both are "x + y", then they
> are actually the same pointer.
Why? We don't currently share expressions in RTL; why would we want to do
so in SIMPLE?
The current simplification code explicitly unshares all the trees to avoid
SAVE_EXPR-like problems with shared expressions. For example, this code
from cppexpr.c:
prio = optab[op].prio - ((optab[op].flags & LEFT_ASSOC) != 0);
gets folded to:
prio = ((int)optab[(unsigned int)op].flags & 2) != 0
? (unsigned int)((int)optab[(unsigned int)op].prio - 1)
: (unsigned int)(int)optab[(unsigned int)op].prio;
where the "optab[op].prio" is shared. If we don't unshare before
simplifying, we get something like (only partially simplified):
T.1 = ((int)optab[(unsigned int)op].flags & 2);
if (T.1 != 0)
{
T.2 = optab[(unsigned int)op].prio;
prio = (unsigned int)((int)T.2 - 1);
}
else
{
prio = (unsigned int)(int)T.2;
}
Oops.
> In other words, statements are the control flow glue that holds
> computations together. The computations don't care about where they
> are in the control flow. This makes some optimizations easier and
> more efficient, and it's a very appealing view of the world.
Sorry, I don't follow. Most computations care very much about where they
are in the control flow; if I move computations about arbitrarily, their
values will tend to change. The value of "x + y" is different before and
after I increment x. It's the job of CSE to recognize when we can share
values between multiple instances of an expression.
Jason