[llvm-dev] relation between address spaces and physical memory locations

Hongbin Zheng via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 23 05:33:03 PDT 2016


Hi,

Is it feasible to assign different DataLayout to different address space in
the same LLVM IR module?

Thanks
Hongbin

On Wed, Mar 23, 2016 at 8:01 PM, David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 23 Mar 2016, at 11:35, Mohammad Norouzi <mnmomn at gmail.com> wrote:
> >
> > Thanks for the reply.
> >
> > On Wed, Mar 23, 2016 at 10:43 AM, James Molloy <james at jamesmolloy.co.uk>
> wrote:
> > Hi,
> >
> > Address spaces in LLVM are an abstract concept and LLVM attaches no
> internal meaning to address spaces, apart from:
> >
> > - Location 0 in address space 0 is 'nullptr' and a pointer to this
> cannot be dereferenced in a well formed program.
> >
> > - pointers in different address spaces cannot alias.
> >
> > 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)
> >
> > When are the meanings attached? After or before register allocation?
>
> 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.
>
> > 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.
>
> 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.
>
> 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.
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160323/9acfa08c/attachment.html>


More information about the llvm-dev mailing list