Re: Extension compatibility policy

[Paul Schlie <schlie at comcast dot net>]

> From: "Joseph S. Myers" <joseph@codesourcery.com>
>>   - and used following the above referenced ""Attribute Syntax", as
>>     either a variable, or function parameter declaration/implementation:
>> 
>>       int ROM x = 3;
>> 
>>       int foo (int ROM y)
>> 
>>     where the parameter's attribute is visible when ever that parameter
>>     is used as an operand within the function tree, and correspondingly
>>     during rtl/template matching; and further if there's an attribute
>>     mismatch between the function argument and it's parameter, the
>>     compiler will warn? (is there any way to force an error instead?)
> ...
> It doesn't seem to me that you've ever implemented target attributes.
> When I last rewrote the attribute handling interfaces and so much of the
> target attribute handling I tried to make sure the interfaces were general
> enough to allow targets to define attributes how they like.  You need to
> make serious experiments with implementing the semantics you want within
> your chosen back ends, looking at all existing back ends for examples of
> what can be done, so questions can be based on real experience rather than
> general lack of understanding.

- This is true, and will invest in experimenting with their implementation.

>> - except that when GCC treats it as a static constant value, accessed during
>>   run-time to initialized the declared variable, just as strings and arrays
>>   are;  it must also have the same attribute the back end is relying on
>>   to identify such references as needing to be accessed differently than
>>   references to other variables are. (so suspect it would be appropriate to
>>   be able to define programmatically an attribute which may be attached to
>>   all such references to initializing data not just strings if not optimized
>>   away, although agree it's not necessary to specify each individually)
> 
> Please write in proper complete coherent English sentences so your
> messages can be understood.

- I'll try again.

> It is a matter for the compiler to determine where it stores data which is
> copied into an object of automatic storage duration as an initializer.

- Yes I understand, and simply assert that when this does occur, they should
  be given the same optional attribute that the analogous compiler generated
  static constant string objects are given; for the same reasons and
  purpose.

> It may be best to emit explicit initialization code; it may be best to
> copy an initialization image; it may be best to call memset and then emit
> initialization code for a few nonzero values.  The compiler can choose
> where that initialization image goes.

- Yes I understand, and further assert that any compiler generated static
  constant objects accessed by reference (as opposed to being embedded in
  the program code itself as either immediate or otherwise generate values)
  for the purpose of run-time initialization of program specified objects,
  should be given the same optional attributes that analogous compiler
  generated static constant string objects are given; for the same reasons
  and purpose.

>                                    ...  This may depend on command-line
> options controlling whether code size, or amount of one sort of data, or
> amount of another sort of data, or speed, should be optimized.  But
> control for individual initializers is not something that makes sense at
> source file level any more than controlling which machine instruction is
> used for a given piece of C code makes sense; if you want to control
> code-generation strategies at that fine a level, write in assembly
> language directly.  (Or provide a static const initialization image with
> the right attributes, then write your own C code to copy it rather than
> using an initializer for the automatic storage duration variable.)

- I fully agree that no finer level of attribute control need be provided
  than deemed appropriate for compiler generated static constant string
  objects; but assert the same attributes should be applied to all analogous
  compiler generated data, regardless of it's type; for the same reasons and
  purpose. (As it's these attributes which has been chosen to identify such
  compiler generated stored data objects.)

More specifically, there seem to be two predominant motivating reasons
why it may be desired to attach a target specified attributes to compiler
generated static constant objects:

1 - To enable their identification so that their compile/link time storage
    location/type may be influenced by the target.

2 - To enable their identification so that their run-time access method may
    be influenced by the target. (Likely due to their storage location/type)

As such, it is imperative that all compiler generated objects, for which
allocated storage is required (beyond alternatively being embedded in the
code as immediate, or otherwise generated values), be enabled to be assigned
the same optional programmatically specified attribute; as they all likely
need to be enabled to be identified and treated analogously.

Thanks for your patience, and will now begin coding per your recommendation.

-paul-