Re: [tree-ssa] Use of build_binary_op

[Jason Merrill <jason at redhat dot com>]

On 26 Sep 2002 12:06:44 +0200, Steven Bosscher <s.bosscher@student.tudelft.nl> wrote:

> If the C-family front ends need a translation from C trees to GIMPLE,
> then why can't lowering of expressions be done on GIMPLE stmt trees.
> That way, the front ends can share the expression simplification
> interface, and they would only have to deal with side effects in
> language specific trees.

Yep, that's the idea.

> So we'd have:
> - a build_* interface for building generic trees
>   (goes/stays in tree.*)

Yes.

> - a build_<lang>_* interface for language specific trees
>   (goes/stays in <lang>-tree.* and c-common.*).

Sure.

> - a build_gimple_* interface for building GIMPLE stmt trees, that is,
>   expressions are *not* lowered here.
> - a gimple_expand_* interface for lowering expressions in GIMPLE trees.

I'm not sure how you intend these to be used.  When would you use
build_gimple_* instead of build_*?

Lowering GENERIC to GIMPLE uses simplify_{expr,stmt}.

> - a gimple_expand_body() to optimize a function body and expand to RTL.

I don't think we need to require GIMPLE form when we enter the tree
equivalent of rest_of_compilation; anything which simplify_expr can handle
should be fine.  I agree that much of the stuff currently in c_expand_body
needs to move into a language-independent file.

> This is more like what we do now with RTL: build and expand stuff
> piecewise. It would allow front ends to optimize the pieces of GIMPLE
> tree, e.g. kill breaks/goto's from loops only. Right now all the
> optimizers work on whole function trees only, even if they don't need SSA
> form.

I don't see any advantage to optimizing each statement as you build it
vs. walking the function tree at end-of-function and optimizing loops as
you find them.  I like the separation of the build and optimization passes.

Also, an optimization like that doesn't sound like it belongs in a
frontend.  I expect there will be some that do, such as operations on
FORTRAN arrays (about which I know nothing), but I still think it makes
most sense to perform them at end-of-function, perhaps before
simplification.

> Some lowering of language specifics would obviously have to be done
> while building GIMPLE stmt trees, so we'd need a formal grammar for
> expressions. The build_gimple_* interface could make sure (perhaps only
> with checking enabled) that any expressions it sees are valid non-simple
> exprs that can be lowered by the gimple_expand_* interface.

There's a very simple rule:  Anything can be lowered by simplify_expr; even
language-specific trees can be lowered using the simplify_expr langhook.
This is what I've done for C.

Jason