<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div>I took a look at what __buildin_shufflevector does.  In that case, it enforces more rules than the type system allow after checking the call.  In that vein, what I could do instead of using this weird type is in <span class="Apple-style-span" style="font-family: Monaco; font-size: 10px; ">ActOnCallExpr,<span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; ">when checking the arguments of an intrinsic call, instead of calling </span></span><div>   <span class="Apple-style-span" style="font-family: Monaco; font-size: 10px; ">CheckSingleAssignmentConstraints</span></div><div><div><div>I could call my own version, e.g., CheckBuiltinAssignmentConstraints that will allow mismatches between address spaces to go through.  How does that sound?</div><div><br></div><div>  -- Mon Ping</div><div><br></div><div><br></div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>From: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Mon P Wang <<a href="mailto:wangmp@apple.com">wangmp@apple.com</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Date: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">July 14, 2008 11:22:42 PM PDT</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>To: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Subject: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica"><b>Re: [cfe-dev] "generic" address space</b></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> </div><div>Hi Eli,<br><br>On Jul 14, 2008, at 10:46 PM, Eli Friedman wrote:<br><br><blockquote type="cite">On Mon, Jul 14, 2008 at 10:21 PM, Mon P Wang <<a href="mailto:wangmp@apple.com">wangmp@apple.com</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">To generate this in Clang, I didn't want to require the user to have<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to specify what specific address spaces a builtin can take, especially<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">if the intrinsic is supported on the address space for a particular<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">machine.  So, I added the concept to ASQualType the concept of a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"generic" address space that can be used in the parameter type of a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">function prototype.   This concept is used when we checking to see if<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">an argument and a parameter type are compatible.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I don't really like this approach: you're introducing a fake type that<br></blockquote><blockquote type="cite">isn't actually usable by user code, which seems messy at best.  I<br></blockquote><blockquote type="cite">think it would be better to handle this like __builtin_shufflevector,<br></blockquote><blockquote type="cite">where typechecking gets done by a custom validator.<br></blockquote><br>What you suggest sounds like a reasonable alternative.  I'll take a look into doing it this way for any built-in of this flavor.<br><br><br><blockquote type="cite"><blockquote type="cite">I'm also going to change clang to generate an error if the compiler<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">needs to do an implicit cast between to pointers pointing at different<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">address spaces.  Typically, this operation doesn't make sense.  Note<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that users can still do explicit cast between address spaces.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I think that's fine; of course, please submit this patch separately.<br></blockquote><br>Sure no problem.<br><br><br>Thanks,<br>  -- Mon Ping<br></div></blockquote></div><br></div>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></div><br></div></div></body></html>