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

David Chisnall via llvm-dev
2016-03-23T12:01:21Z

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