[cfe-dev] Adding memory spaces to types

Steve Naroff snaroff at apple.com
Wed Nov 14 06:00:18 PST 2007


On Nov 13, 2007, at 10:59 PM, Chris Lattner wrote:

>>> However,  this optimization for CVR qualifiers doesn't impact other
>>> "qualifiers".  It would be very reasonable to have an
>>> AddressSpaceQualifiedType class, which takes an address space ID
>>> and a QualType.   This combines the space/time efficiency niceties
>>> of QualType with the generality of having explicit classes for all
>>> of these.
>>
>> Good to hear. I had proceeded with this approach and have some
>> simple cases working (all the way through LLVM back end and
>> generating assembly, not bad for  2 evenings work!). I had to make
>> some guesses about all the functions that need to see "through" the
>> ASQualType, but I figured it would be mostly similar to other types
>> that wrap another type (Complex, Vector, etc.) with a few additions.
>
> Nice!
>
>> Also, address space qualifiers need to be parsed like other type CVR
>> qualifiers,
>
> Right.
>
>> rather than using an attribute, because attributes seem to apply to
>> the entire Decl irrespective of where in Decl the attribute occurs
>> (is this purposeful, or just the current state?).
>
> 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.

Syntactically, attributes can be on the "DeclSpec" or the  
"Declarator" (see DeclSpec.h for some more comments). This models what  
GCC does.

Semantically, all the attributes are (currently) associated with the  
Declarator. Since we haven't implemented many attributes yet, it's  
entirely possible that we need to associate "DeclSpec" attributes with  
the eventual type.

snaroff



More information about the cfe-dev mailing list