[PATCH] PR30391: GIMPLE_MODIFY_STMT vs. middle-end

[Diego Novillo]

Roger Sayle wrote on 02/04/07 23:08:

> The perhaps controversial solution proposed below is to accept that the
> middle-end needs to manipulate to forms of assignments, one for use in
> expressions, the other for use in statements.  The statement form should
> never be used in an expression context, and the expression form should
> never be used in a statement context.  Indeed in Computer Science terms we
> might denote one as "=" and the other as ":=".
> 
I wonder if this is this the long term design we want to maintain.
One of the goals of the tuples design is to completely separate the
physical data structures used by the front ends (ASTs) and the middle
end (tuples).

This does mean that we will have two different sets of fold()
interfaces.  However, folding GIMPLE expressions should be a lot
simpler than folding arbitrary ASTs.

> This ideological separation is maintained by the programmer based upon
> context.
>
The idea is that this need not be programmer maintained.  I would like
us to move all the GIMPLE IL into a physically separate data
structure.  This will force much better separation between ASTs and
tuples, and between the front ends and middle end.

> Whilst I agree with the original goal of the tuples design to completely
> obsolete MODIFY_EXPR once we'd entered the late middle-end, unfortunately
>
Not only MODIFY_EXPR.  GIMPLE is to become a completely different data
structure.

> stream or the CFG.  For example, during RTL expansion we may need to
> temporarily create assignments to be expanded, and there's no strong
> reason for these to use the same doubly linked data structure that we use
> for representing functions.
> 
Yup, I agree.  But in the future we may elect to build tuples
instead of ASTs, depending on what we're building.

> The following patch has been tested on i686-pc-linux-gnu, with a full
> "make bootstrap", all default languages including Ada, and regression
> tested with a top-level "make -k check" with no new failures.  This patch
> is effectively the first of another transition, where all existing uses of
> "build2 (GIMPLE_MODIFY_STMT, ..." are either transformed into
> "build_gimple_stmt" or "{fold_}build2 (MODIFY_EXPR, ..." depending upon
> context.
> 
Having a build_gimple_stmt is fine, but the function should take
a code.  We are going to have several codes for GIMPLE statements
(conditionals, function calls, PHI functions, etc).