Re: [RFC] Contributing tree-ssa to mainline

[kenner@vlsi1.ultra.nyu.edu (Richard Kenner)]

    > The Ada tree has *a lot* more information than can be (or should be)
    > encoded into the GCC tree datastructure.  Each tree node has 183
    > defined flags, for example.

    When the time comes to generate GENERIC from Ada, then that
    information should be propagated down.  

I disagree.  I see no reason to find ways of representing the sort of
language-specific information that's encoded there.  Sure, some of that is
used for code generation information and is propagated down, but most of it
is not and need not be.  If you're curious about what kinds of information is
in Ada tree nodes, look at ada/einfo.ads and ada/sinfo.ads.  Note that the
Ada tree is a parse tree augmented with semantic information, rather than a
purely semantic tree like GCC.

    One thing that I'm vaguely concerned regarding Ada is the potential of
    having to create new GIMPLE trees.  Having to create new GENERIC codes
    wouldn't be a problem, but adding GIMPLE means changing the optimizers
    as well.

I don't know enough about GIMPLE to answer that and I think it's not
practical to answer that for certain at least until "old-style"
function-at-a-time is working for Ada, but as long as there's handling for
the present PLACEHOLDER_EXPR and WITH_RECORD_EXPR, which seems to me to be
needed at that level (though perhaps it might not be), I doubt there should
be any significant issue here.

    I only meant checks that need dataflow information.  If the
    elimination needs dataflow information, then the FE will be
    duplicating code and effort.

Not necessarily.  If the front end is already tracking some dataflow for its
own purposes and can use that knowlege to eliminate a check, why would it be
better for it *not* to do so?  As I said, all over GCC we're doing
"duplicate" simplifications and the fact that we do so is one of the major
strengths of the compiler.

    There has been some discussion of perhaps lowering ARRAY_REFs.  But
    that would be done relatively late in the tree pipeline.

Good, because that's my concern: the form of the subscript information is
critical to many high-level loop optimizations.  If you're going to have to
figure that out from an address computation, you're giving up much of the
benefit of doing that optimization on trees instead of RTL>