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: Language-independent functions-as-trees representation


>>>>> "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


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