Re: Extension compatibility policy

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 1 Mar 2005, Paul Schlie wrote:

>   - an attribute may be defined, such as:
> 
>     #define ROM __attribute__("ROM");
> 
>   - 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 is entirely up to the back end to define what attributes can be used 
(TARGET_ATTRIBUTE_TABLE), how they can be used, what default attributes 
there are (TARGET_SET_DEFAULT_TYPE_ATTRIBUTES, TARGET_INSERT_ATTRIBUTES) 
and what their type compatibility rules are (TARGET_COMP_TYPE_ATTRIBUTES, 
TARGET_MERGE_TYPE_ATTRIBUTES, TARGET_MERGE_DECL_ATTRIBUTES) (there are a 
few more hooks as well).  Rather than asking questions about 
hypotheticals, work out what you want the semantics for your back end to 
be (write them down at the ISO standard level of detail, including exactly 
how your attributes fit into the type system, as qualifiers, storage class 
specifiers or otherwise and into constraints on assignment etc.), 
implement them and test them and only is you find some *specific* problem 
with the hooks available and how they are used, *then* report the problem 
with a *clear and specific* explanation of what the problem is, e.g. that 
the hooks don't allow for a certain type of compatibility checking.

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.

> - 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.

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.  
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.  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.)

You will need to understand the core code in GCC that determines what 
initialization strategy to use in a particular case.  Once you've found 
and understood that code, and how target macros and hooks affect it, you 
may then find that a particular target has requirements for initialization 
strategy different from those the current hooks handle.  If so, write an 
explanation - in coherent complete grammatical English sentences, not 
telegraphese - of the current interfaces, why they do not suffice for your 
target, and of a proposed new interface to meet your target's 
requirements, get consensus on that interface and implement it.  But the 
right approach is going to be to allow such target control by the back 
end, not to have control at source file level for individual initializers, 
although quite possibly you could implement an attribute on a variable 
which controls the initialization strategy for that variable (NB an 
attribute on the variable, using existing syntax, not one on the 
initializer itself) - I just don't think it would be useful to do so.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)