Re: [tree-ssa] Use of build_binary_op

[Pop Sébastian <pop at gauvain dot u-strasbg dot fr>]

On Wed, Sep 25, 2002 at 11:04:57PM +0100, Jason Merrill wrote:
> 
> > I don't say that we have to switch from the lowering of C/C++ trees to
> > this translation point of view
> 
> I don't see the distinction.  Lowering of C/C++ trees involves this sort of
> translation...
> 
You're right since bnw no longer simplify C or C++ into a 
subset language, but it also introduces new expressions.  
Sorry for the confusion, I will try to be more precise.

What I mean by lowering is the transformation of a language 
into a subset of the same language that contains less possible 
constructs.  A translation is a transform from a language A to 
another language B.

In tree-ssa-branch, for the moment, there's a lowering from C to 
a subset of C: SIMPLE.  In the bnw branch there is a lowering, 
as before for SIMPLE, _and_ a translation:

C trees       -> GIMPLE trees
------------------------------

FOR_STMT      -> LOOP_EXPR
WHILE_STMT    -> LOOP_EXPR
DO_STMT       -> LOOP_EXPR

GOTO_STMT     -> GOTO_EXPR
CONTINUE_STMT -> GOTO_EXPR
BREAK_STMT    -> GOTO_EXPR

LABEL_STMT    -> LABEL_EXPR
IF_STMT       -> COND_EXPR
SWITCH_STMT   -> SWITCH_EXPR
CASE_LABEL    -> CASE_LABEL_EXPR
ASM_STMT      -> ASM_EXPR
SCOPE_STMT    -> BIND_EXPR


Isn't this translation independent of expression lowering?
I think that we can separate them and run at first the translation, 
then run on this new language the lowering:
	C specific trees  ->  GIMPLE  ->  lowered GIMPLE
For the C and C++ front-ends it's no worth to separate the translation
from the lowering, but for other languages I think that having an 
interface for building generic trees then an interface for lowering 
this tree could be of help.

G95 uses is_simple_* functions.  That means that for building valid trees 
they have to keep track of the lowering stuff as well, when they would
just need a generic tree interface.

I think that we have to define an interface on both lowered and 
non lowered GIMPLE.  Then we'd have:
- a build_* interface for front-end specific trees,
- a generic_build_* interface for building non lowered GIMPLE trees,
- a simple_build_* interface for transformations on lowered trees,
- an expand_* interface for translating GIMPLE to RTL,
(and get rid of genrtl_* interface that works on statements).