This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Richard Kenner wrote:

This is the patch I spoke about this morning.  Much of it is mechanical, but
a good part is not.

I've been working on an x86_64 target.  It's at the point where all languages
except Ada (there's still some work to do there, as I said) bootstrap,
everything builds, there are no C regressions and only the C++ regression I
mentioned this morning.

At this point, I felt it best to get it out of my tree and into the head
where people can bash away at it and also help to get any remaining problems
(and I'm sure there will be) fixed.  There are also a few things that need to
be tweaked a bit, but that too will easier once it's checked in.  This patch
is too large and affects too many files to keep locally for too much longer,
but too small to justify a branch.

I think everybody agrees on the general overview of what I did and it's
easier to deal with details now that it's checked in.

I don't agree.

In particular, you've just added an extra entry to ARRAY_REF and COMPONENT_REF, making these two common tree nodes bigger. (COMPONENT_REF, in particular, is used extensively in C++; every access to a class member variable is a COMPONENT_REF.) These extra entries are unnecessary in C and C++, meaning that for GCC's two most-used languages you've just increased memory usage with no benefit. If you need some additional stuff for Ada, please find a way that doesn't penalize C and C++.

Furthermore, you didn't update the c-tree.texi documentation. You also didn't add accessor macros for these additional operands, so the only place to look is at the documentation you added in tree.def, which suggests that these additional operands are redundant; for example, the third operand in a COMPONENT_REF is defined in terms of the DECL_FIELD_OFFSET of the second operand; if that's true, why do we need to have it there explicitly? Presumably, this has something to do with variable-sized types, but the documentation does not say what that is. If that's what this is about, then I suggest you find a way to make these nodes bigger in Ada than it is in C/C++ and only look for the additional fields there, or have a flag in ARRAY_REF that indicates whether these additional fields are present.

Please revert this patch until we've got consensus here.


Mark Mitchell
CodeSourcery, LLC
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]