* Re: Why is the TREE_PURPOSE of a CONSTRUCTOR_ELT list for ARRAY_TYPE NULL?
@ 2004-09-06 20:20 Richard Kenner
0 siblings, 0 replies; 6+ messages in thread
From: Richard Kenner @ 2004-09-06 20:20 UTC (permalink / raw)
To: dberlin; +Cc: gcc
Except in the constructors i'm dealing with (C++ vtables, represented as
arrays), all the TREE_PURPOSES in the constructor list are NULL.
Does that mean that the corresponding index is the last index + 1?
In any case, is this a documentation bug, or a C++ FE bug (IE should i
expect tree_purpose to always be there, and it's just not getting set in
the case of the C vtables, or do the docs need updating)?
It's a C++ FE bug. Before tree-ssa, TREE_PURPOSE could be (and often was)
NULL, but it can't be now.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why is the TREE_PURPOSE of a CONSTRUCTOR_ELT list for ARRAY_TYPE NULL?
2004-09-08 21:35 ` Joseph S. Myers
@ 2004-09-08 21:41 ` Mark Mitchell
0 siblings, 0 replies; 6+ messages in thread
From: Mark Mitchell @ 2004-09-08 21:41 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Richard Henderson, Daniel Berlin, gcc
Joseph S. Myers wrote:
>On Wed, 8 Sep 2004, Mark Mitchell wrote:
>
>
>
>>In fact, I've been thinking that we should design a new datastructure for
>>CONTRUCTORs like so:
>>
>> struct initializer_chunk {
>> tree base;
>> tree count;
>> struct initializer_chunk *next;
>> tree *elems[1];
>> };
>>
>>with the idea of making these initializers vastly more compact.
>>
>>Yes, this is only a constant-factor improvement, but on test cases with large
>>arrays (of which there are plenty) this could very well result in the
>>difference between fitting in RAM and not fitting in RAM.
>>
>>
>
>Perhaps we should also call them something other than CONSTRUCTOR, given
>the several different meanings that word has.
>
>
Yes.
>I wonder if the common case is that large initializers are mostly
>compile-time constants so all you need store is an array of target bytes
>(at the expense of greater complexity when you then want to extract a
>particular constant element).
>
>
I think that is probably the common case for very large initializers
(big bitmaps, data tables, etc). So, you're right that this might make
sense. However, sometimes there are relocations against these
constants because they're runtime constants, rather than compile-time
constants. Virtual tables, with their pointers-to-functions, are in
this category.
So, I'd still go with my suggestion as a first cut; then, you could add
a discriminator bit and turn elems into a union member with "byte_t
*data" as the other element in the union.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why is the TREE_PURPOSE of a CONSTRUCTOR_ELT list for ARRAY_TYPE NULL?
2004-09-08 20:49 ` Mark Mitchell
@ 2004-09-08 21:35 ` Joseph S. Myers
2004-09-08 21:41 ` Mark Mitchell
0 siblings, 1 reply; 6+ messages in thread
From: Joseph S. Myers @ 2004-09-08 21:35 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Richard Henderson, Daniel Berlin, gcc
On Wed, 8 Sep 2004, Mark Mitchell wrote:
> In fact, I've been thinking that we should design a new datastructure for
> CONTRUCTORs like so:
>
> struct initializer_chunk {
> tree base;
> tree count;
> struct initializer_chunk *next;
> tree *elems[1];
> };
>
> with the idea of making these initializers vastly more compact.
>
> Yes, this is only a constant-factor improvement, but on test cases with large
> arrays (of which there are plenty) this could very well result in the
> difference between fitting in RAM and not fitting in RAM.
Perhaps we should also call them something other than CONSTRUCTOR, given
the several different meanings that word has.
I wonder if the common case is that large initializers are mostly
compile-time constants so all you need store is an array of target bytes
(at the expense of greater complexity when you then want to extract a
particular constant element).
Cf. <http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00253.html> and
predecessors (some of them in the previous month).
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why is the TREE_PURPOSE of a CONSTRUCTOR_ELT list for ARRAY_TYPE NULL?
2004-09-07 20:03 ` Richard Henderson
@ 2004-09-08 20:49 ` Mark Mitchell
2004-09-08 21:35 ` Joseph S. Myers
0 siblings, 1 reply; 6+ messages in thread
From: Mark Mitchell @ 2004-09-08 20:49 UTC (permalink / raw)
To: Richard Henderson; +Cc: Daniel Berlin, gcc
Richard Henderson wrote:
>On Mon, Sep 06, 2004 at 03:55:49PM -0400, Daniel Berlin wrote:
>
>
>>Does that mean that the corresponding index is the last index + 1?
>>
>>
>
>Yes.
>
>
>
>>In any case, is this a documentation bug, or a C++ FE bug (IE should i
>>expect tree_purpose to always be there, and it's just not getting set in
>>the case of the C vtables, or do the docs need updating)?
>>
>>
>
>We should probably change the vtable builder to fill in the values.
>
>
For an ten-million element array, this will result in ten million
integer constants.
In fact, I've been thinking that we should design a new datastructure
for CONTRUCTORs like so:
struct initializer_chunk {
tree base;
tree count;
struct initializer_chunk *next;
tree *elems[1];
};
with the idea of making these initializers vastly more compact.
Yes, this is only a constant-factor improvement, but on test cases with
large arrays (of which there are plenty) this could very well result in
the difference between fitting in RAM and not fitting in RAM.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why is the TREE_PURPOSE of a CONSTRUCTOR_ELT list for ARRAY_TYPE NULL?
2004-09-06 19:55 Daniel Berlin
@ 2004-09-07 20:03 ` Richard Henderson
2004-09-08 20:49 ` Mark Mitchell
0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2004-09-07 20:03 UTC (permalink / raw)
To: Daniel Berlin; +Cc: gcc
On Mon, Sep 06, 2004 at 03:55:49PM -0400, Daniel Berlin wrote:
> Does that mean that the corresponding index is the last index + 1?
Yes.
> In any case, is this a documentation bug, or a C++ FE bug (IE should i
> expect tree_purpose to always be there, and it's just not getting set in
> the case of the C vtables, or do the docs need updating)?
We should probably change the vtable builder to fill in the values.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Why is the TREE_PURPOSE of a CONSTRUCTOR_ELT list for ARRAY_TYPE NULL?
@ 2004-09-06 19:55 Daniel Berlin
2004-09-07 20:03 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Berlin @ 2004-09-06 19:55 UTC (permalink / raw)
To: gcc
The documentation claims:
For ARRAY_TYPE:
The TREE_PURPOSE of each node is the corresponding index.
If the TREE_PURPOSE is a RANGE_EXPR, it is a short-hand for many
nodes,
one for each index in the range. (If the corresponding TREE_VALUE
has side-effects, they are evaluated once for each element. Wrap the
value in a SAVE_EXPR if you want to evaluate side effects only once.)
Nothing in there says it could be NULL.
Except in the constructors i'm dealing with (C++ vtables, represented as
arrays), all the TREE_PURPOSES in the constructor list are NULL.
Does that mean that the corresponding index is the last index + 1?
In any case, is this a documentation bug, or a C++ FE bug (IE should i
expect tree_purpose to always be there, and it's just not getting set in
the case of the C vtables, or do the docs need updating)?
I'm trying to figure out whether i need to submit a patch to the
documentation, or the C++ FE :)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-09-08 21:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-06 20:20 Why is the TREE_PURPOSE of a CONSTRUCTOR_ELT list for ARRAY_TYPE NULL? Richard Kenner
-- strict thread matches above, loose matches on Subject: below --
2004-09-06 19:55 Daniel Berlin
2004-09-07 20:03 ` Richard Henderson
2004-09-08 20:49 ` Mark Mitchell
2004-09-08 21:35 ` Joseph S. Myers
2004-09-08 21:41 ` Mark Mitchell
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).