<div dir="ltr">Hi,<div><br></div><div>Is it feasible to assign different DataLayout to different address space in the same LLVM IR module?</div><div><br></div><div>Thanks</div><div>Hongbin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 23, 2016 at 8:01 PM, David Chisnall via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 Mar 2016, at 11:35, Mohammad Norouzi <<a href="mailto:mnmomn@gmail.com">mnmomn@gmail.com</a>> wrote:<br>
><br>
> Thanks for the reply.<br>
<span class="">><br>
> On Wed, Mar 23, 2016 at 10:43 AM, James Molloy <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>> wrote:<br>
> Hi,<br>
><br>
> Address spaces in LLVM are an abstract concept and LLVM attaches no internal meaning to address spaces, apart from:<br>
><br>
> - Location 0 in address space 0 is 'nullptr' and a pointer to this cannot be dereferenced in a well formed program.<br>
><br>
> - pointers in different address spaces cannot alias.<br>
><br>
> Different backends attach different meanings. So for example an OpenCL backend might interpret address space 1 as local memory, 2 as private memory etc (in fact for OpenCL, these mappings are defined in the Clang frontend, if I recall correctly)<br>
><br>
</span>> When are the meanings attached? After or before register allocation?<br>
<br>
The meanings are target specific.  They are assigned by the targets.  Note that the C address space and the LLVM IR address space do not always correspond - Clang’s OpenCL mode, for example, maps OpenCL address spaces to different IR address spaces depending on the target.<br>
<br>
> This is important as register allocation can use this information to allocate registers to variables. For example, in a parallel code we have shared and private variables. Shared variables should not go into registers. This alleviates register pressure.<br>
<br>
I think that you are talking about something different to what I understand register allocation to mean.  For most targets, values must be in registers (or, at least, one of a pair of values must be) to be used by instructions.  If they reach the back end without a canonical memory location then they are not referenced by address and so may end up solely in registers, or on the stack.  If they are referenced by address, then they must be loaded before being computed on and assignments will require a store.<br>
<br>
For parallel code, this may make a difference to instruction selection (for example, you don’t need atomic operations on private variables), but shouldn’t make a different to register allocation.<br>
<br>
David<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>