Re: Patch to allow Ada to work with tree-ssa

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

    I'm not disputing that you fixed a bug with these patches; what I'm 
    saying is that there must be a better way to fix it.

I'm open to the possibility of there being a better way to fix it, but
nobody's come up with one yet.  This was not my first choice.  As I said, my
first proposal was indeed to do this without increasing the size of the nodes
(which I didn't care for either), but that was strongly opposed by many people.

    Many of us cannot read GCC mail on a continuous basis.  

Yeah, but I'd say it's rare to read gcc-patches on a more continuous basis
than the GCC list!

    It's was originally a C and C++-specific file; now, it's the closest 
    thing we have to tree documentation.  It certainly documents ARRAY_REF 
    and COMPONENT_REF.

OK, I can add it to that, but I suggest that somebody with access to the
repository rename the file to a more lanuage-independent name.

    In their plain English meaning, the words you wrote in tree.def make
    these fields redundant; you have defined the values of these fields in
    terms of information already available in the tree.  You've suggested
    that this is not actually true; that they are conveying some
    information not already present -- but the words you've written do not
    make clear what that is.  For example, "Operand 2 is a copy of
    TYPE_MIN_VALUE of the index."  OK, then, why don't we just do
    TYPE_MIN_VALUE (TREE_TYE (TREE_OEPRAND (x, 1)))?  Why store this in
    the node?  That is not explained in your documentation.

OK.  Will fix.

    I am very much against increasing the size of COMPONENT_REF and
    ARRAY_REF for C++.  I've suggested a technical solution: add a flag to
    the nodes that says whether they have all the fields, or just the old
    ones.  Presumably, it will be very rare in C/C++ to have all the
    fields.  True, we don't have that yet -- but, I'm confident you can
    find a way.

Sure, I can "find a way" to have such a flag, but doing it in general is
going to have a cost penalty because TREE_OPERAND would have to become a
call.  We'd be trading a very small size cost for a large compute cost.
Better would be to have two node types, but that would complicate GIMPLE,
which also has its downside.

    I recognize that you estimated conservatively, 

*very* conservatively!

Nathan and Zack, what are the actual percentage of ARRAY_REF and
COMPONENT_REF?  I used 12.5% and 25%, but it wouldn't surprise me if that was
high by a factor of at least four.

    but we should not be making changes that increase memory usage,

As they say, "you can't make an omelet without breakings eggs". Although
keeping memory usage down is a worthwhile goal, it's not an absolute.  After
all, the concept of gimplifying creates extra nodes, as does tree-ssa.  One
of the major things discussed at the GCC summit was to add more annotations
to names and that takes memory.  A discussion that I started last week led to
a belief that an UID concept for statements is important for debugging the
compiler and that will take space too.

    That's fine with me if you will agree to implement the optimization
    where these nodes are smaller when the extra fields are not needed, or
    implement new tree nodes for VARIABLE_ARRAY_REF or
    VARIABLE_COMPONENT_REF.  An even easier change would be to embed the
    additional fields in one of the existing operands; have the second
    operand be a TREE_LIST, or some such, in the case where there is a
    need for this additional information.  Ugly, but effective.

Certainly, I'll be glad to make a pass over this change and implement
something else, but both of the above have the attribues that they are in
GIMPLE and hence need to be known about by all the tree optimizers.

Another approach that would address your concerns about permanent memory,
would be to go the other way and have the nodes used by the front end for
ARRAY_REF and COMPONENT_REF be different from those used by the tree
optimizers (the latter will always have four fields) and have the gimplifier
convert.

But I'd also like to see Nathan and Zack weigh in here because their work
may become relevant too and they'll have the accurate statistics.