This is the mail archive of the
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Per Bothner <per at bothner dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 22 Jul 2002 17:02:12 -0400
- Subject: Re: Language-independent functions-as-trees representation
- Organization: Red Hat Canada
- References: <firstname.lastname@example.org>
On Sat, 20 Jul 2002, Jason Merrill wrote:
> I'd like to return to the discussion of a language-independent
> functions-as-trees representation that was going on in January. At this
> point I'd like to ignore the question of representation within a particular
> frontend (INITIAL?), and focus on what the frontend hands off to the
> middle-end (GENERIC?) and the simplified form which is used in
> optimization (SIMPLE).
I'm curious about GENERIC. Currently we are making each front
end do an INITIAL->SIMPLE pass via the simplify_function_tree
hook. What advantage do you see in having INITIAL->GENERIC->SIMPLE?
> Per argues that having (for example) both IF_STMT and COND_EXPR is
> gratuitous duplication. rth argues that at the SIMPLE level we want to
I don't have a strong opinion on this. All we need is to be able
to do traversals of this kind:
for every basic block B
for every stmt S in B
for every expr E in S
whether statements have different codes or are just of type
'void' is the same to me. But we need to know whether a tree
node affects flow of control or not. That's important
for building the flowgraph.
> We still need to address the issue of expressing ordering requirements in
> SIMPLE, as discussed in the third thread above. For instance, currently
Nothing was decided. I think that SEQUENCE_POINT or BARRIER
nodes should be sufficient. Data dependencies will dictate
natural sequences in the code. We can then insert barriers when
we need to express partial orderings. Or maybe, have SEQUENCE
regions (BEGIN_SEQUENCE / END_SEQUENCE).
> In a previous thread, Diego has suggested that inlining would be done on
> language-dependent trees. I think this is a mistake; IMO it should be done
> at the SIMPLE level. Requiring the inliner to know about frontend trees is
Ah, yes. I have changed my mind since then. One of the
suggestions for doing a Java inliner was to write the
simplification pass for Java and use the existing C inliner.