[LLVMdev] [cfe-dev] Language-specific vs target-specific address spaces (was Re: [PATCH] OpenCL support - update on keywords)

[Speziale Ettore]

Hi,

> On Mon, Feb 28, 2011 at 4:41 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> >
> > The more I think about it, the more I become uncomfortable with the
> > concept of language-specific address spaces in LLVM.  These are the
> > main issues I see with language-specific address spaces:
> 
> ...
> 
> > Instead of language-specific address spaces, each target should
> > concentrate on exposing all of its address spaces as target-specific
> > address spaces, and frontends should use a language -> target mapping
> > in target-specific code.  We can continue to expose the target's main
> > shared writable address space as address space 0 as we do now.
> >
> > For example, Clang could define a set of internal address space
> > constants for OpenCL and use TargetCodeGenInfo to provide the mapping
> > to target address spaces.
> 
> In principle this is a fine idea.
> 
> I think the difficulty is that LLVM and Clang provide an
> infrastructure for numbered address spaces, but no standard assignment
> on top of that infrastructure.  The trick is define some conventions,
> e.g. what the numbers might mean for a language front-end, and whether
> the interpretation of the numbers change as the IR moves to later
> stages.  We're working in a bit of a vacuum.
> 
> For example, you're proposing a remapping step somewhere along the
> line: that could be entirely inside a back-end code generator.  Or it
> could conceivably be an LLVM pass itself, which then could be used
> with multiple backends that understand the new convention.
> 
> So I think we need a couple of things:
> - proposals for number assignments and their associated semantics.
> - code to flesh out and embody those semantics. e.g. a sample
> implementation / translation layer
> 
> Basically Anton got the ball rolling: his code patch was a bit of
> both.  And I think he's planning to post a number of OpenCL proposals
> in general.
> 
> As it is, I hope that backends that do not understand address spaces
> at all know to error out when they receive IR that uses address
> spaces.

The OpenCL standard talks about addess spaces, but I think they can be
interpreted as scopes (except __constants):

* __global: globally accessible variables
* __private: visible only to a work item
* __local: accessible by all work item in a work group

The address space is the way scoping rules are implemented in hardware,
e.g __local variables are mapped in the address space X which is a fast
memory shared by all ALU inside a GPU multiprocessor. Maybe introducing
such "scopes", it is possible to decouple backends fom frontends.

__constant is a corner case: it can be modelled as a global scope that
contains read only data

Have a nice day,
speziale.ettore at gmail.com