[cfe-dev] Adding memory spaces to types

[Christopher Lamb]

On Nov 10, 2007, at 6:43 PM, Chris Lattner wrote:

> On Nov 10, 2007, at 1:59 AM, Christopher Lamb wrote:
>> I've been playing around with clang/LLVM looking at adding partial  
>> support for the draft technical report for embedded C extensions  
>> (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ 
>> n1169.pdf), in particular: memory spaces.
>
> Nice!
>
>> It's been fairly simple to thread memory space ID's through LLVM  
>> so far, but I'm new to FE's and the language from the TR has left  
>> me wondering about the best way to implement this in clang. From  
>> TR18037:
>>
>> Clause 6.2.5 - Types, replace the second sentence of paragraph 25  
>> with:
>>
>> Each unqualified type has several qualified versions of its type, 
>> 38) corresponding to the combinations
>> of one, two, or all three of the const, volatile, and restrict  
>> qualifiers, and all combinations
>> of any subset of these three qualifiers with one address space  
>> qualifier.  (Syntactically, an address
>> space qualifier is an address space name, so there is an address  
>> space qualifier for each visible
>> address space name.)
>>
>> The question I have is, how to track this info without adding  
>> memory space id's to QualType, which seems
>> (1) infeasible given the implementation of QualType as a smart  
>> pointer with only a few bits for additional data, and
>> (2) would loose the performance benefit of the current QualType  
>> implementation (and thus the whole purpose of QualTypes existence,  
>> it seems) if QualType were made extensible.
>>
>> My first thought was to create a new Type subclass called  
>> MemSpacedType that would essentially just be used to store the  
>> memory space ID in addition to the QualType of the underlying  
>> type. Is this the way to go? I'm deep in new territory and need  
>> some seasoned advice.
>
> Yep, I think this is a very reasonable way to go.  QualType itself  
> is just an optimization for representing types.  Instead of having  
> Type*'s everywhere, and having a "ConstType" type and  
> "RestrictType" type (that wrapped some other type), the information  
> is encoded into QualType.
>
> 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.

Also, address space qualifiers need to be parsed like other type CVR  
qualifiers, 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?).

_SpaceA int * foo;
is not
int * _SpaceA foo;

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?

The LLVM infrastructure supports a limited number of address spaces  
(N) and I was planning on having built in support for qualifiers of  
the form '_AddressSpace#' for all N. The TR says that a means to  
define new address spaces may be provided by the compiler, and if  
there are in-fact AddressSpaceType's would it be reasonable to think  
that a typedef would be the correct means of binding a name to a  
numbered AddressSpace?

allowing:
typedef _AddressSpace12 twelfth_space;
typedef _AddressSpace12 space_12;

also, this would allow the compiler to be "preloaded" with typedefs  
for memory spaces based on the target, would it not?

--
Christopher Lamb




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20071110/9cc2cabd/attachment.html>