From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
To: mark@codesourcery.com
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Patch to allow Ada to work with tree-ssa
Date: Tue, 22 Jun 2004 20:22:00 -0000 [thread overview]
Message-ID: <10406221849.AA08790@vlsi1.ultra.nyu.edu> (raw)
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.
next reply other threads:[~2004-06-22 18:47 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-22 20:22 Richard Kenner [this message]
2004-06-22 20:30 ` Mark Mitchell
-- strict thread matches above, loose matches on Subject: below --
2004-07-29 19:02 Richard Kenner
2004-07-29 18:43 Richard Kenner
2004-07-29 17:12 Richard Kenner
2004-07-29 17:13 ` Diego Novillo
2004-07-29 17:57 ` Richard Henderson
2004-06-25 15:28 Richard Kenner
2004-06-28 15:09 ` Paolo Bonzini
2004-06-24 15:58 Richard Kenner
2004-06-24 16:04 ` Nathan Sidwell
2004-06-25 14:43 ` Joseph S. Myers
2004-06-23 5:54 Richard Kenner
2004-06-23 2:32 Richard Kenner
2004-06-23 4:54 ` Bryce McKinlay
2004-06-23 0:16 Richard Kenner
2004-06-22 23:05 Richard Kenner
2004-06-23 11:42 ` Nathan Sidwell
2004-06-22 22:18 Richard Kenner
2004-06-23 1:07 ` Richard Henderson
2004-06-22 21:30 Richard Kenner
2004-06-22 22:04 ` Paul Brook
2004-06-22 21:27 Richard Kenner
2004-06-22 21:29 ` Mark Mitchell
2004-06-22 21:10 Richard Kenner
2004-06-22 21:12 ` Mark Mitchell
2004-06-22 22:16 ` Daniel Berlin
2004-06-22 21:07 Richard Kenner
2004-06-22 21:12 ` Bryce McKinlay
2004-06-22 21:05 Richard Kenner
2004-06-22 21:01 Richard Kenner
2004-06-22 20:54 Richard Kenner
2004-06-22 21:06 ` Paul Brook
2004-06-22 21:37 ` Richard Henderson
2004-06-22 20:44 Richard Kenner
2004-06-22 21:03 ` Mark Mitchell
2004-06-23 20:58 ` Geoffrey Keating
2004-06-22 20:40 Richard Kenner
2004-06-22 22:02 ` Nathan Sidwell
2004-06-22 22:27 ` Joseph S. Myers
2004-06-22 20:23 Richard Kenner
2004-06-22 20:37 ` Joseph S. Myers
2004-06-23 20:47 ` Geoffrey Keating
2004-06-24 14:59 ` Joseph S. Myers
2004-06-24 16:26 ` Richard Earnshaw
2004-06-24 19:57 ` Laurent GUERBY
2004-06-24 20:06 ` Diego Novillo
2004-06-24 20:24 ` Andrew Pinski
2004-06-24 22:35 ` Laurent GUERBY
2004-06-24 21:33 ` Laurent GUERBY
2004-06-24 21:01 ` Joseph S. Myers
2004-06-25 14:51 ` Richard Earnshaw
2004-06-22 19:05 Richard Kenner
2004-06-22 20:10 ` Joseph S. Myers
2004-06-22 20:27 ` Andrew Haley
[not found] <10406221359.AA05860@vlsi1.ultra.nyu.edu>
2004-06-22 18:47 ` Richard Henderson
2004-06-22 18:33 Richard Kenner
2004-06-22 18:19 Richard Kenner
2004-06-22 18:36 ` Nathan Sidwell
2004-06-22 18:37 ` Nathan Sidwell
2004-06-22 18:45 ` Mark Mitchell
2004-06-22 17:05 Richard Kenner
2004-06-22 17:21 ` Andrew Haley
2004-06-22 19:01 ` Richard Henderson
2004-06-22 16:34 Richard Kenner
2004-06-22 16:33 Richard Kenner
2004-06-22 17:46 ` Mark Mitchell
2004-06-22 18:17 ` Joseph S. Myers
2004-06-22 18:52 ` Richard Henderson
2004-06-22 19:37 ` Zack Weinberg
2004-06-22 7:05 Richard Kenner
2004-06-22 7:29 ` Mark Mitchell
2004-06-22 9:14 ` Andrew Pinski
2004-06-22 14:16 ` Andrew Haley
2004-06-22 11:00 ` Richard Henderson
2004-06-22 13:52 ` Ranjit Mathew
2004-07-29 17:02 ` Diego Novillo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10406221849.AA08790@vlsi1.ultra.nyu.edu \
--to=kenner@vlsi1.ultra.nyu.edu \
--cc=gcc-patches@gcc.gnu.org \
--cc=mark@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).