<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi, <div><br></div><div>I agree with you that AST should be as strongly typed as possible and be consistent. (BTW, does clang handle K&R C and formal conversions when one doesn't see the prototype, i.e., the automatic promotion to double and then converting it back to float). If we want to make it very clear on the AST, we could create a special operator that indicates that a address mismatch is allowed. I'm not sure what to call it but it is more of an type adaptor than a conversion. This would make it very clear at the AST what is going on without resorting to a weird placeholder type. Another possibility is that we could tag the <span class="Apple-style-span" style="font-family: Monaco; font-size: 10px; ">ParmVarDecl<span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; "> to indicate that this parameter can ignore any address space differences between the argument and the parameter.</span></span></div><div><br></div><div> -- Mon Ping</div><div><br></div><div><br></div><div><div>On Jul 15, 2008, at 10:56 PM, Eli Friedman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Tue, Jul 15, 2008 at 10:28 PM, Mon P Wang <<a href="mailto:wangmp@apple.com">wangmp@apple.com</a>> wrote:<br><blockquote type="cite">Hi Eli,<br></blockquote><blockquote type="cite">Whatever we do, it should be clear when examining the AST that we are<br></blockquote><blockquote type="cite">matching an address space overloaded intrinsic. I'm not sure what new AST<br></blockquote><blockquote type="cite">expression tree would make sense. I view it that we have an call expression<br></blockquote><blockquote type="cite">to an address space overloaded intrinsic function. When we check the<br></blockquote><blockquote type="cite">argument and parameter of the signature, the normal rules follow except for<br></blockquote><blockquote type="cite">parameters that can accept different address space.<br></blockquote><br>The issue is that the types of the function arguments won't match the<br>type of the call, which would be surprising for most AST consumers.<br><br><blockquote type="cite">It is a bit unclear to me what happens with intrinsics that can take any<br></blockquote><blockquote type="cite">integer width. Looking briefily, it looks like clang will generate an<br></blockquote><blockquote type="cite">implicit cast for the argument to integer. Do we always generate the 32 bit<br></blockquote><blockquote type="cite">integer version of these intrinsics?<br></blockquote><br>Mmmm, it looks like clang's versions of the __sync_* builtins are<br>broken in that respect. I think some custom logic is needed for the<br>overloading.<br><br><blockquote type="cite">Various DSPs (e.g TI TMS320C30), embedded architectures and GPUs support<br></blockquote><blockquote type="cite">different address spaces. The Cell processor has local<br></blockquote><blockquote type="cite">memory accessible only by the SPUs. Nvidia and AMD GPUs typically have<br></blockquote><blockquote type="cite">different address spaces for things like local or textures. It is difficult<br></blockquote><blockquote type="cite">to get their ISAs though AMD has released their R600 ISA<br></blockquote><blockquote type="cite">(<a href="http://www.x.org/docs/AMD/r600isa.pdf">http://www.x.org/docs/AMD/r600isa.pdf</a>). I'll have to look to see what is<br></blockquote><blockquote type="cite">available publicly.<br></blockquote><br>Hmm, okay... I'm trying to get a feel for what sorts of intrinsics for<br>alternate address spaces we'll want, and for which ones it's useful to<br>overload the address space of the pointer arguments. For example, for<br>the R600 ISA (which I skimmed), I can't think of any intrinsics for<br>which overloading would be useful; it seems like the address spaces<br>are implied by the instruction. Do you have any examples where it<br>would be useful to overload the address space of platform-specific<br>intrinsics?<br><br>-Eli<br></div></blockquote></div><br></body></html>