Re: Language-independent functions-as-trees representation

[Jason Merrill <jason at redhat dot com>]

>>>>> "Diego" == Diego Novillo <dnovillo@redhat.com> writes:

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

Modularity, mainly.  The idea is that by the time we get to the
simplification stage there won't be any language-specific trees to worry
about.

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.

Any other opinions?

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

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.

On the other side, a COMPOUND_STMT doesn't affect flow of control; it's
just a way of grouping things at the same level.

I suppose to me, the distinction is not about any intrinsic property of the
statement, it's whether or not its value is used in further calculations.
In expand_expr terms, whether or not "ignore" is true.

>> 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).

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.

Jason