[LLVMdev] Address space extension

[Michele Scandale]

On 08/08/2013 03:52 AM, Pete Cooper wrote:
>> Why a backend should be responsible (meaning have knowledge) for a
>> mapping between high level address spaces and low level address spaces?
> Thats true.  I’m thinking entirely from the persecutive of the backend
> doing CL/CUDA.  But actually LLVM is language agnostic.  That is still
> something the metadata could solve.  The front-end could generate the
> metadata i suggested earlier which will tell the backend how to do the
> mapping.  Then the backend only needs to read the metadata.

 From here I understand that in the IR there are addrspace(N) where 
N=0,1,2,3,... according to the target independent mapping done by the 
frontend to represent different address spaces (for OpenCL 1.2 0 = 
private, 1 = global, 2 = local, 3 = constant).

Then the frontend emits metadata that contains the map from "language 
address spaces" to "target address spaces" (for X86 would be 0->0 1->0 
2->0 3->0).

Finally the instruction selection will use these informations to perform 
the instruction selection correctly and tagging the machine instruction 
with both logical and physical address spaces.

>> Why X86 backend should be aware of opencl address spaces or any other
>> address spaces?
> The only reason i can think of is that this allows the address space
> alias analysis to occur, and all of the optimizations you might want to
> implement on top of it.  Otherwise you’ll need the front-end to put
> everything in address space 0 and you’ll have lost some opportunity to
> optimize in that way for x86.

The mapping phase will allow to have to have the backend precondition 
satisfied (no address spaces other than zero). Having in the IR and also 
after both informations the alias analysis should be feasible.

>> Like for other aspects I see more direct and intuitive to anticipate
>> target information in the frontend (this is already done and accepted)
>> to have a middle-end and back-end source language dependent (no
>> specific language knowledge is required, because different frontends
>> could be built on top of this).
>>
>> Maybe a way to decouple the frontend and the specific target is
>> possible in order to have in the target independent part of the
>> code-generator a support for a set of language with common concept
>> (like opencl/cuda) but it's still language dependent!
> Yes, that could work.  Actually the numbers are probably not the
> important thing.  Its the names that really tell you what the address
> space is for.  The backend needs to know what loading from a local
> means.  Its almost unimportant what specific number a front-end chooses
> for that address space.  We know the front-end is really going to choose
> 2 (from what you said earlier), but the backend just needs to know how
> to load/store a local.
>
> So perhaps the front-end should really be generating metadata which
> tells the target what address space it chose for a memory space.  That is
>
> !private_memory = metadata !{ i32 0 }
> !global_memory = metadata !{ i32 1 }
> !local_memory = metadata !{ i32 2 }
> !constant_memory = metadata !{ i32 3 }
>
> Unfortunately you’d have to essentially reserve those metadata names for
> your use (better names than i chose of course), but this might be
> reasonable.  You could alternately use the example I first gave, but
> just add a name field to it.
>
> I guess targets would have to either assert or default to address space
> 0 when they see an address space without associated metadata.

This part is not clear, still in the X86 backend private/global/local 
memories are meaningless. Indeed it is limited to a set of languages 
that support these abstractions.

IMO a more general solution would be to fully demand to the frontend the 
mapping resolution generating the map from logical to physical address 
spaces.

Considering also the fact that addrspace is used to support C address 
space extension that maps from C to physical numbered address spaces, 
maybe a default implicit identity function as mapping would be fine when 
no metadata are not provided.


Thanks again.

-Michele