Re: Question on aggregates and GIMPLE

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    I disagree.  Personally I see this as Ada front-end bits having
    unnecessarily percolated into the middle-end.  It's easy to 
    understand how that could happen with you maintaining gcc for
    all those years.

But that's not the correct history! This code was in GCC from the very
beginning, well before the GNAT project was even started at NYU.  The same is
true for nested functions.  Indeed, it's exactly the other way around: the
GNAT project used GCC precisely because all these things were already there!

The *only* things added to GCC to support Ada were VIEW_CONVERT_EXPR (which
also turns out to be useful in C), ARRAY_RANGE_EXPR, PLACEHOLDER_EXPR and
WITH_RECORD_EXPR and the latter was removed recently.

We certainly contemplated adding support at the tree level for other Ada
constructs, but never got the chance to do it.  Early on we were very careful
to add as little as possible.  In retrospect, we probably should have added
*more* (look at how much Pascal-specific stuff is there), but we didn't.

(The other historical inaccuracy is that the start of the GNAT project was
very close to when I *stopped* being the GCC maintainer!)

    What you're saying is that we the tree-ssa team should have blindly
    re-implemented every strange quirk that might be hiding in expr.c
    without regard to whether or not it's still useful, used, or indeed
    the best approach to the problem at hand.

    I think not.

Well, the history isn't too relevant, but my view is that it would have been
nice if we'd had a precisely-written specification of what the existing tree
language supported.  Then it would have either implemented those things or
very explicitly chosen (by negotation with the rest of the community) not to.

But there was no such specification.  In some sense, the code in expr.c
served as that specification.  In retrospect, one approach would have had the
first task of the tree-ssa project to write such a specification, publish it
to the community, and decide what to implement.  But in the absence of that
formal task, I would indeed expect everything to be implemented.

    Indeed, I'd like to take this opportunity to move stuff that's really
    Ada specific back into the Ada front end.  That's not going to be all
    of the things you find, certainly, but definitely some of it.

In my mind, the issue is whether the operation could benefit from high-level
optimizations.  Certainly, if you're seeing an assignment as an assignment
between two variables, you have a much better chance of seeing that the
assignment is dead or redundant than you do if you represent that assignment
as a complex set of pointer computations and dereferences.  Likewise for
comparisons: jump threading would be hopeless if they were expanded.

    Comparison of aggregates should be right at the top of that list.
    We've already heard from Paul that expanding to memcmp would be
    incorrect for Fortran; an existance proof that this is indeed a
    language-specific semantic and thus should be handled by the language.

Not at all!  Indeed in most cases comparisons of aggregates are
field-at-a-time in Ada too, and in those cases the front end makes those
individual comparisons and uses ANDs to chain them together.  But if what
you're doing in *either* language is comparing two arrays of characters,
memcmp is precisely what you want and having a straightforward tree
representation of the comparison best allows high-level optimizations.

If I write S (3..5) = "xyz" I'd really like that to survive in the tree
as an <EQ_EXPR <ARRAY_RANGE_EXPR <S 3>> <STRING_CST "xyz">> so the 
optimizers can reason on that basis and if it later saw S (3..5) = "abc",
it would know that only one of those can be true.  Sure, we perhaps can't
do that kind of optimization today, but one day we'll be able to and it's
precisely that sort of optimization that I think will be the largest
benefit of the infrastructure we're creating.