This is the mail archive of the gcc@gcc.gnu.org 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: [tree-ssa] Use of build_binary_op


On Thu, 26 Sep 2002 10:40:51 +0200, Pop Sébastian <pop@gauvain.u-strasbg.fr> wrote:

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

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

OK, yes.  Simplifying C involves both translation from C frontend trees to
generic trees, and lowering to simpler forms of the generic trees.

> Isn't this translation independent of expression lowering?

It can be.  When working on bnw-simple-branch, I found it simplest to do
the translation in the context of simplification, but it mostly works by
translating all of the _STMT nodes, and then simplifying the result.

> 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

I would say               ->  GENERIC ->  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.

I think that in most cases, build/build1 is sufficient, but I certainly
don't object to having generic functions that perform a bit more
processing, like build_addr_expr in c-simplify.c (though it should move to
another file).

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

Agreed, there's no reason for G95 to use those functions except in a
simplifier langhook.

> I think that we have to define an interface on both lowered and 
> non lowered GIMPLE.

Why would they need to be different?

Jason


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