<div>
<div>Thanks, Chris.</div>
<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>I don't know how much magic is inherent in this language extension. Would it be bad to to make __vector *always* be on when AltiVec is enabled (whether or not it is followed by a 'numeric type keyword')? We could then make 'vector' be fuzzier. I'm still vaguely uncomfortable with 'vector' changing semantics depending on its lexical context, but understand that you probably don't have a choice here :)</div>
</blockquote></div>
<div><br>I think I see. Treat "__vector" as a normal keyword token, and if "vector" is encountered, I still do the context check and effectively treat it as "__vector"?</div>
<div> </div>
<div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>Sure, if that works! I don't know what __vector does. </div></blockquote></div>
<div> </div>
<div>My understanding is that "__vector" (or "vector") in this context is always followed by a numeric type, i.e. "_vector unsigned int". My guess was that this would be effecticvely equivalent to "__attribute__((vector_size(16))) unsigned int", so the plan would then be to have the resulting type for these two be the same after the semantic action.<br>
</div>
<div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>I think so, though we also need an 'altivec.h' for clang to use, in a similar spirit to 'xmmintrin.h' for sse.</div></blockquote>
<div> </div>
<div>Yes, probably, if nothing else just to be compatible with gcc. (It's mentioned in the Altivec standard in section 2.6 of <a href="http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf">http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf</a>). I was told it was orginally deprecated, but then left in to help with early implementation. Looking at the one we have for the PS3 gcc compiler, it seems to be the PowerPC version, and mostly just maps Altivec names to the "__builtin_*" functions.</div>
</div>
<div> </div>
<div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>Yes. However, noone has done any ABI compatibility testing on PowerPC, even for simple types. It is likely that there are a bunch of bugs passing structures by value etc. Daniel has a nice randomized testcase generator for finding cases that need to be improved. </div>
</blockquote></div>
<div> </div>
<div>I guess we'll have to cross that bridge when we get to it.</div>
<div> </div>
<div>-John</div>
<div> </div>
<div> </div>
<div class="gmail_quote">On Tue, Dec 8, 2009 at 10:47 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On Dec 7, 2009, at 12:55 PM, John Thompson wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">1. In implementing vector and __vector, which is better?:<br></blockquote><br></div>I'm not familiar with the intricacies of this extension, so I don't know the technical feasibility of the different approaches, but here's MHO:
<div class="im"><br><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><br>A. Don't make it a keyword, but if LangOptions::AltiVec is set and a kw_identifier with the name "vector" or "__vector" is followed by a numeric type keyword, make the type a vector type.<br>
</blockquote><br></div>This would be the "context sensitive keyword" approach I guess. I tend to not like this because it can be fragile / unpredictable.
<div class="im"><br><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"> B. Make vector and __vector a keyword if LangOptions::AltiVec is set, and if not followed by a numeric type keyword, treat it as an identifier.<br>
My guess is that A is better as it involves less fixing up of cases where an identifier with the name of "vector" can occur.<br></blockquote><br></div>I don't know how much magic is inherent in this language extension. Would it be bad to to make __vector *always* be on when AltiVec is enabled (whether or not it is followed by a 'numeric type keyword')? We could then make 'vector' be fuzzier. I'm still vaguely uncomfortable with 'vector' changing semantics depending on its lexical context, but understand that you probably don't have a choice here :)
<div class="im"><br><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><br>2. Regarding the typing, I'm thinking internally it would be treated just as if __attribute__((vector_size(16)) were applied to the type, right?<br>
</blockquote><br></div>Sure, if that works! I don't know what __vector does.
<div class="im"><br><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">3. With __attribute__((vector_size(16)), does the Clang code generation already output everything LLVM needs to support the Altivec vectors?<br>
</blockquote><br></div>I think so, though we also need an 'altivec.h' for clang to use, in a similar spirit to 'xmmintrin.h' for sse.
<div class="im"><br><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">For example, in looking at the code generated for some code using an "__attribute__((vector_size(16)) float" variable or return type, the .ll file uses "<4 x float>". On a PowerPC platform supporting Altivec, does LLVM automatically know to map that to a vector register?<br>
</blockquote><br></div>Yes. However, noone has done any ABI compatibility testing on PowerPC, even for simple types. It is likely that there are a bunch of bugs passing structures by value etc. Daniel has a nice randomized testcase generator for finding cases that need to be improved.
<div class="im"><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><br>4. I'm guessing the Altivec functions can be implemented as Clang built-in functions that map to calls to LLVM's altivec intrinsic functions, right? I haven't researched this much yet.<br>
</blockquote><br></div>Yes, we support the 'unusual' altivec builtins in llvm-gcc by mapping them onto the LLVM intrinsics in llvm/include/llvm/IntrinsicsPowerPC.td. The simple ones make directly onto llvm IR vector instructions.<br>
<font color="#888888"><br>-Chris<br><br></font></blockquote></div><br><br clear="all"><br>-- <br>John Thompson<br><a href="mailto:John.Thompson.JTSoftware@gmail.com">John.Thompson.JTSoftware@gmail.com</a><br><br>