From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16914 invoked by alias); 22 Jun 2004 18:47:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 16905 invoked from network); 22 Jun 2004 18:47:39 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org with SMTP; 22 Jun 2004 18:47:39 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA08790; Tue, 22 Jun 04 14:49:10 EDT Date: Tue, 22 Jun 2004 20:22:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10406221849.AA08790@vlsi1.ultra.nyu.edu> To: mark@codesourcery.com Subject: Re: Patch to allow Ada to work with tree-ssa Cc: gcc-patches@gcc.gnu.org X-SW-Source: 2004-06/txt/msg01779.txt.bz2 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.