[LLVMdev] Address space extension

[Micah Villmow]

Michele, 
 Why can not the target triple implicitly encode the address space mapping? I would not expect address spaces to map correctly if I compile OpenCL code on an AMD device and then compile the IR on an NVidia device. Even an AMD device targeted from OpenCL could have a different mapping than the same AMD device targeted from C++AMP, DirectX or OpenGL. Address space mapping should be part of the ABI definition and be part of the contract between the frontend and the backend. Adding extra information in the metadata would then be redundant.

Micah

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Michele Scandale
> Sent: Friday, August 09, 2013 9:42 AM
> To: James Courtier-Dutton
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Address space extension
> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev