[LLVMdev] Address space extension

[Micah Villmow]

> -----Original Message-----
> From: Michele Scandale [mailto:michele.scandale at gmail.com]
> Sent: Friday, August 09, 2013 11:41 PM
> To: Micah Villmow
> Cc: James Courtier-Dutton; LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Address space extension
> 
> Hi Micah,
> 
> On 08/10/2013 06:01 AM, Micah Villmow wrote:
> > 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.
> 
> Sure the IR would have some target dependences that prevents its usage as is
> with another target: this is a good point I haven't taken into account.
> 
> I don't like the idea to "encode" this mapping within the triple known by LLVM:
> this would be equivalent to make backends ware of language-specific features,
> like the choices of logical address space mapping done by frontends. My
> objection is: why if I want to use LLVM as a tool for a "new" language (a "new"
> frontend) that uses address spaces I should modify also LLVM to add a new
> triple variant to specify my mapping?
[Micah Villmow] The backends won't understand your address space mapping. The backends should expose their address spaces that they support, their sizes and their overall semantics. It should be documented just like the calling convention is documented. It is then the job of the frontend to map whatever source language address spaces are used onto the correct address spaces for the target. For example, the AMDIL backend supports multiple address spaces. If your new language has more than 1 address space, then your frontend has to map them to the backend's address spaces at compile time based on the target triple.  If they don't map directly, then you will have to just use the default for all of them. As someone who has written three backends, it is entirely unrealistic to expect all of the backends to support any variable address space setup. It is quite annoying and messy to deal with, as I've done it. One, although hacky, way to work around it is to have the backend support a language specific option on how to interpret address spaces.

> 
> I agree with you that this mapping is a "static" property of the contract
> between the frontend and the backend so it is confusing to put this information
> in the module.
> 
> A solution would be something like the current "TargetTransformInfo" for
> represent source language details, e.g. a LanguageTransformInfo pass:
> this kind of pass would be registered by the frontend in building process of the
> compiler pipeline (the information about the mapping may be required also in
> the middle end indirectly, e.g. to know the bitsize of a pointer of a given logical
> address space).
> 
> The address space map function would fit perfectly as a property for such a
> structure, would create a safe and static way for frontends to honoring the
> contract with backends.
> 
> There is a big limitation: without such a pass in the compiler pipeline the
> correctness of code generation is not guaranteed (e.g. how can I use 'llc'
> without specifying this pass?).
> 
> Thanks.
> 
> -Michele