<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>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>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><br class="webkit-block-placeholder"></div>Nice!</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><div>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><br class="khtml-block-placeholder"></div><div><i>Clause 6.2.5 - Types, replace the second sentence of paragraph 25 with: </i></div><div><i> <br class="khtml-block-placeholder"></i></div><div><i>Each unqualified type has several qualified versions of its type,38) corresponding to the combinations </i></div><div><i>of one, two, or all three of the const, volatile, and restrict qualifiers, and all combinations </i></div><div><i>of any subset of these three qualifiers with one address space qualifier. (Syntactically, an address </i></div><div><i>space qualifier is an address space name, so there is an address space qualifier for each visible </i></div><div><i>address space name.)</i></div><div><br class="khtml-block-placeholder"></div><div>The question I have is, how to track this info without adding memory space id's to QualType, which seems </div><div>(1) infeasible given the implementation of QualType as a smart pointer with only a few bits for additional data, and</div><div>(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><br class="khtml-block-placeholder"></div><div>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></div><div>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><br class="webkit-block-placeholder"></div><div>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><div><br class="webkit-block-placeholder"></div><div>-Chris</div></body></html>