This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Use of build_binary_op
On Thu, Sep 26, 2002 at 10:28:33AM +0100, Jason Merrill wrote:
> 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
>
No problem, thus I guess that GIMPLE = Generic SIMPLified.
> > 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).
>
Another reason I want this separation an never directly use build/build1 is
because build/build1 uses the underlying structures (the big enum with all
tree nodes). If we define explicitely the interface it becomes possible
to replace this representation by another one... just by replacing these
constructors by new ones (but that is still work in progress...)
> > 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?
>
since you could just say that GENERIC and GIMPLE trees are of different types.
But in C we don't have support for such fine type declarations...
Sebastian