<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On Nov 13, 2007, at 10:59 PM, Chris Lattner wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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></BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Nice!</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Also, address space qualifiers need to be parsed like other type CVR qualifiers,</DIV></BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Right.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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></BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><BR><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_SpaceA int * foo;</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">is not</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">int * _SpaceA foo;</DIV></BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><BR><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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></BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_SpaceA int * foo;</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">void bar() {</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "> typedef int _SpaceA;</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "> _SpaceA y; // int y.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">}</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR style=""></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Is this really intended?</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Here's the specific language. I misread it.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>5.1.2 Address-space type qualifiers</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">Each address space other than the generic one has a unique name in the form of an identifier. </SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">Address space names are ordinary identifiers, sharing the same name space as variables and</SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">typedef names.</SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">Any such names follow the same rules for scope as other ordinary identifiers (such</SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">as typedef names).</SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">An implementation may provide an implementation-defined set of </SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"><I>intrinsic</I></SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">address spaces that are, in effect, predefined at the start of every translation unit.</SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">The names of</SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">intrinsic address spaces must be reserved identifiers (beginning with an underscore and an</SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">uppercase letter or with two underscores).</SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">An implementation may also optionally support a means</SPAN></FONT><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;"> </SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 11px;">for new address space names to be defined within a translation unit.</SPAN></FONT></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ; color: rgb(0, 0, 221); ">I would strongly prefer some way for the various target-specific memory spaces to be handled without having to hack the parser, I don't know if this is possible though.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I prefer less parser hacking as well. I'm voting for being able to apply attributes to types as well as the whole decl. =)</DIV></DIV><DIV><DIV><BR class="khtml-block-placeholder"></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>