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/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
