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

On Fri, Aug 23, 2002 at 01:41:28PM +0100, Jason Merrill wrote:
> rth has raised some questions about the advisability of using COMPOUND_EXPR
> to chain statements; the current scheme uses TREE_CHAIN of the statements
> themselves.

Indeed.  I'm not really sure what to do about this either.  Per's scheme
of using chained array fragments to reduce the memory allocation overhead
also complicates the act of iteration (without moving to C++ with more
abstract iterators).

It'd be nice if the thingy used here were exactly 3 words long (next,
prev, expr), and avoided the extra tree overhead.  Perhaps that's too
much to hope for.

Perhaps this can be deferred for now by creating some 
FOR_EACH_STMT (STMT, START) macros that do the iteration.  Then we
can replace the iteration implementation more easily later.

> To me, the benefit is modularity; apart from the earlier
> complaints about the STMT/EXPR distinction, using COMPOUND_EXPR makes it
> easy to replace a single complex expression with a sequence of simple ones,
> simply by plugging in a COMPOUND_EXPR in its place.  The current scheme
> requires a lot more pointer management in order to splice the new STMTs in
> at both ends.

I don't see this as particularly compelling.  Write one function
to do the splice and it's done.

> From an optimization perspective, are LABELED_BLOCK_EXPR/EXIT_BLOCK_EXPR
> easier to deal with than plain gotos?

Perhaps, but since gotos have to be handled in any case, two passes
are required for CFG construction.  I guess the main point of having
something of this form is for goto-elimination vs switch statements.

Though I don't see the point of LABELED_BLOCK_EXPR; EXIT_BLOCK_EXPR
could just as well refer to the stmt tree that it exits.

> I assume they're preferable to the
> current loosely bound BREAK_STMT, which has no information about what it's
> exiting.  EXIT_EXPR would have the same problem if it were used to express
> 'break'.

Yes, I really dislike having such loosely-bound constructs persisting
this long.  This goes for BREAK, EXIT, and CASE_LABEL.

>    switch-stmt:
>        op0 -> val
>        op1 -> stmt

Speaking of CASE_LABEL, one way to fix that would be to have the
SWITCH_EXPR have a vector that mapped indicies to plain old LABEL_EXPRs.
Thoughts here?  Perhaps I am making too much work for the front end?

> I'm not sure how we want to represent throws for the purpose of to
> generating an ERT_THROW region?  I had thought about using a THROW_EXPR
> wrapper, but that wouldn't work in non-simplified code where calls can have
> complex args.  Perhaps annotation of the CALL_EXPR would work better.


>    varname : compref | ID (rvalue)
>    lhs: varname | '*' ID  (lvalue)

Is this lhs really correct?  Surely ID (rvalue) isn't valid here.
Oughtn't it be

	lhs: compref | ID (lvalue) | * ID (rvalue)


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