Re: Why is the TREE_PURPOSE of a CONSTRUCTOR_ELT list for ARRAY_TYPE NULL?

[Mark Mitchell <mark@codesourcery.com>]

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