<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Nov 10, 2007, at 6:43 PM, Chris Lattner wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style=""><DIV style="">On Nov 10, 2007, at 1:59 AM, Christopher Lamb wrote:</DIV><BLOCKQUOTE type="cite"><DIV style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV style="">I've been playing around with clang/LLVM looking at adding partial support for the draft technical report for embedded C extensions (TR18037, <A href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf</A>), in particular: memory spaces.</DIV></DIV></BLOCKQUOTE><DIV style=""><BR class="webkit-block-placeholder"></DIV>Nice!</DIV><DIV style=""><BR style=""><BLOCKQUOTE type="cite"><DIV style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV style="">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:</DIV><DIV style=""><BR class="khtml-block-placeholder"></DIV><DIV style=""><I>Clause 6.2.5 - Types, replace the second sentence of paragraph 25 with: </I></DIV><DIV style=""><I> </I><BR class="khtml-block-placeholder"></DIV><DIV style=""><I>Each unqualified type has several qualified versions of its type,38) corresponding to the combinations </I></DIV><DIV style=""><I>of one, two, or all three of the const, volatile, and restrict qualifiers, and all combinations </I></DIV><DIV style=""><I>of any subset of these three qualifiers with one address space qualifier. (Syntactically, an address </I></DIV><DIV style=""><I>space qualifier is an address space name, so there is an address space qualifier for each visible </I></DIV><DIV style=""><I>address space name.)</I></DIV><DIV style=""><BR class="khtml-block-placeholder"></DIV><DIV style="">The question I have is, how to track this info without adding memory space id's to QualType, which seems </DIV><DIV style="">(1) infeasible given the implementation of QualType as a smart pointer with only a few bits for additional data, and</DIV><DIV style="">(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.</DIV><DIV style=""><BR class="khtml-block-placeholder"></DIV><DIV style="">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.</DIV></DIV></BLOCKQUOTE><BR style=""></DIV><DIV style="">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.</DIV><DIV style=""><BR class="webkit-block-placeholder"></DIV><DIV style="">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.</DIV></BLOCKQUOTE><BR></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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?).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>_SpaceA int * foo; </DIV><DIV>is not</DIV><DIV>int * _SpaceA foo; </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>allowing:</DIV><DIV>typedef _AddressSpace12 twelfth_space;</DIV><DIV>typedef _AddressSpace12 space_12;</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>also, this would allow the compiler to be "preloaded" with typedefs for memory spaces based on the target, would it not?</DIV><BR><DIV><DIV>--</DIV><DIV>Christopher Lamb</DIV><DIV><BR class="khtml-block-placeholder"></DIV></DIV><BR><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>