<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Eli,</div><div><br></div><div>Whatever we do, it should be clear when examining the AST that we are matching an address space overloaded intrinsic. I'm not sure what new AST expression tree would make sense. I view it that we have an call expression to an address space overloaded intrinsic function. When we check the argument and parameter of the signature, the normal rules follow except for parameters that can accept different address space. During code generation, the different argument type will generate a slightly different intrinsic function like @llvm.atomic.load.add.i32.p0i32. </div><div><br></div><div>It is a bit unclear to me what happens with intrinsics that can take any integer width. Looking briefily, it looks like clang will generate an implicit cast for the argument to integer. Do we always generate the 32 bit integer version of these intrinsics?</div><div><br></div><div>Various DSPs (e.g TI TMS320C30)<span class="Apple-style-span" style="font-family: 'Times New Roman'; font-size: 16px; line-height: 19px; "><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; line-height: normal; ">, embedded architectures and GPUs support different address spaces. The Cell processor has local memory accessible only by the SPUs. Nvidia and AMD GPUs typically have different address spaces for things like local or textures. It is difficult to get their ISAs though AMD has released their R600 ISA (<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 available publicly. </span></span></div><div><br></div><div>-- Mon Ping</div><div><br></div><div><div>On Jul 15, 2008, at 6:42 PM, Eli Friedman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Tue, Jul 15, 2008 at 5:38 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"><br></blockquote><blockquote type="cite">On an architecture that support address spaces, any builtins that touches<br></blockquote><blockquote type="cite">memory would probably need this support. Today, I think it's mostly the<br></blockquote><blockquote type="cite">sync functions. For a specific architecture, one is likely to add<br></blockquote><blockquote type="cite">architecture specific built-ins to support some other operations that<br></blockquote><blockquote type="cite">touches memory and I would like to use the same mechanism (e.g., specialized<br></blockquote><blockquote type="cite">load/store instructions) to do the check.<br></blockquote><br>Ah, I see... I hadn't really considered the arch-specific builtins<br>part. In that case, adding some generic machinery might be<br>appropriate. That said, I've never actually seen an architecture with<br>multiple address spaces, so pointers to any documentation would be<br>helpful.<br><br>I don't think we should be abusing existing machinery to handle this<br>case; therefore, I think there should be a new kind of AST expression<br>for address-space-overloaded intrinsics. This makes it explicit that<br>there is something unusual going on with the types for such intrinsic<br>calls.<br><br>-Eli<br></div></blockquote></div><br></body></html>