[cfe-dev] Adding memory spaces to types

[Chris Lattner]

>>> Also, the TR specifies that the names of address spaces are in the  
>>> type namespace. My question is, does that mean there also needs   
>>> to be an AddressSpaceType class?
>>
>> I haven't read the TR closely, but if it says this, it is very  
>> strange :).  I think this means that _SpaceA can't be either a  
>> macro or a typedef.  The issue is that it being a type means that  
>> this should be legal (assuming _SpaceA is a valid space for the  
>> current target:
>>
>> _SpaceA int * foo;
>>
>> void bar() {
>>   typedef int _SpaceA;
>>   _SpaceA y;  // int y.
>> }
>>
>> Is this really intended?
>
> Here's the specific language. I misread it.
>
> 5.1.2 Address-space type qualifiers
>
> Each address space other than the generic one has a unique name in  
> the form of an identifier.
> Address space names are ordinary identifiers, sharing the same name  
> space as variables and
> typedef names.  Any such names follow the same rules for scope as  
> other ordinary identifiers (such
> as typedef names).  An implementation may provide an implementation- 
> defined set of intrinsic
> address spaces that are, in effect, predefined at the start of every  
> translation unit.  The names of
> intrinsic address spaces must be reserved identifiers (beginning  
> with an underscore and an
> uppercase letter or with two underscores).  An implementation may  
> also optionally support a means
> for new address space names to be defined within a translation unit.

Okay, this is goodness.  This means the builtin ones can just be  
macros that expand out to an attribute, or anything else convenient.

>> I don't recall off-hand.  Steve is the guru of attributes, though  
>> Nate may also know.  It would certainly be nice to have these be  
>> typedefs or #defines for __attribute__ syntax, just to avoid having  
>> to tweak the parser for each device that needs address spaces.
>
> I wholeheartedly agree. My first implementation used attributes, but  
> fails the test below. I looked at what it would take to get the  
> parser to understand otherwise and it seemed very non-trivial.  
> Especially because the number and name of keywords is target  
> specific it'd need something akin to attribute parsing, but just for  
> namespaces. Doesn't seem worth it.

Yep.

>>> _SpaceA int * foo;
>>> is not
>>> int * _SpaceA foo;
>>
>> If attributes don't support this mechanism right now, I think we  
>> should extend them to work with it.  A specific attribute (e.g.  
>> "address_space" in __attribute__((address_space(1)))) should be  
>> markable as applying to the type instead of the decl.
>
> Named address spaces were implemented using attributes successfully  
> by Codeplay in the VectorC compiler that I have experience with, so  
> I agree that it would be good to have this functionality.

Ok, so it sounds like the right approach is to extend our current  
attribute support to allow them to be applied in-place to the types as  
they are parsed.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20071114/2a7af674/attachment.html>