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


On Tue, Jul 23, 2002 at 06:01:21PM +0100, Jason Merrill wrote:
> On the other hand, going from INITIAL to GENERIC will use a lot of the same
> functionality as from GENERIC to SIMPLE, so perhaps it would be simpler
> just to go straight to SIMPLE, using a langhook to handle language-specific
> trees.

I think I like this idea.  I can't imagine except that it'd be
faster, and use less memory in the process.

> > But we need to know whether a tree
> > node affects flow of control or not.  That's important
> > for building the flowgraph.
> 
> Well, anything that can trap affects flow of control; in C++, most function
> calls have edges to the local exception handler.  In Java, some arithmetic
> does as well.

Yes, but I'd say that traping arithmetic cannot be a nested expression.
It would only be able to appear as the statement "t = a op b".  Perhaps
similarly with trapping memory references.

> I think we also need something to express the absence of ordering
> restrictions.  If we write f(g(), h()), there will be a sequence point
> after each of the calls to g and h (at least in C++).  Or if they're
> inlined, within the calls.  We need to make it explicit that despite the
> presence of sequence points, the optimizer can switch the two around.
> That's why I was suggesting something like UNORDERED_LIST.

Alternately, the number of places in which this applies seems
relatively limited.  We might be able to do with a langhook 
that says what order in which arguments may be evaluated.

What other benefits do we get from the complexity of expressing
the partial ordering of expressions?


r~


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