llvm dev - Mar 2016 - relation between address spaces and physical memory locations

Hi,

Do address spaces in llvm corespond to different memory locations? For
example, Shared and Global refer to RAM while Local refers to registers?

I guess that this may be true in GPU programming. So, I would like to know
about CPUs.

Thanks.

Best,
Mohammad
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160323/0ee73916/attachment.html>

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)

Cheers,

James

On Wed, 23 Mar 2016 at 09:31, Mohammad Norouzi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> Do address spaces in llvm corespond to different memory locations? For
> example, Shared and Global refer to RAM while Local refers to registers?
>
> I guess that this may be true in GPU programming. So, I would like to know
> about CPUs.
>
> Thanks.
>
> Best,
> Mohammad
>
>
> _______________________________________________
> 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/aef17f2f/attachment.html>

On 23 Mar 2016, at 09:43, James Molloy via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> - pointers in different address spaces cannot alias. 
This is also target specific.  In our back end, the two address spaces that we
use can alias (we use address spaces for indicating different kinds of pointer,
rather than different kinds of underlying memory).

If address spaces could never alias, then there would be no need for an address
space cast instruction, as the result would always be an invalid value.

David

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

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>