[LLVMdev] Address space extension

[Michele Scandale]

Hello James,

I've some doubts about what you are proposing...

> A suggestion:
> Define/describe each address space in the lower layer of LLVM. <- all
> the target specific info.
> E.g. Address space 0 is 64bits and needs specific instructions to access it.
> The LLVM IR can query the lower layer when it needs to know a
> description of address space 0 during an optimization step.
> CLANG then queries LLVM for address space description when it needs it.
>  From the description, LLVM IR or CLANG then make their own choices:
> E.g. CLANG decides for itself if, based on the address space
> description, address space 0 is local, private or global.
> The description of each address space would need to cover all the
> different types of address space there are in enough detail. I.e. Not
> just the bitsize, but also whether pointers can be converted from one
> address space to another or not, and if so, how.

What if a target have only *one address space*? How in the IR I can 
distinguish two logical address spaces if the query result is just one?

What if there are no objective informations useful to make a choice?

What if the desired behavior is *just a choice*?

These descriptions should be language independent, otherwise it would be 
fine just to encode a static mapping.

Indeed for the optimization, the high level semantic is what we want to 
describe too, e.g OpenCL disjoint address spaces mey be mapped to the 
same physical address space, but still they are disjoint! We would need 
a query system from LLVM to CLANG.

> One advantage of this approach is that the "CLANG deciding for itself
> whether address space 0 is local, private or global" only needs to
> happen once, instead of needing to process it every time the metadata
> appears (if it was stored in metadata instead).

The mapping should be encoded in clang, so it's static and it would be 
just a table. Metadata would be emitted by clang in order to allow the 
middle end and the backend to do correctly their job.

Thanks for your future reply.

-Michele