[LLVMdev] Address space extension

[Micah Villmow]

> -----Original Message-----
> From: Michele Scandale [mailto:michele.scandale at gmail.com]
> Sent: Saturday, August 10, 2013 6:29 AM
> To: Micah Villmow
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Address space extension
> 
> On 08/10/2013 02:47 PM, Micah Villmow wrote:
> > Michele,
> >  The information you are trying to gather is fundamentally static information,
> and as such can be implicit. It doesn't matter what OpenCL program you are
> trying to compile, the address space information for each backend doesn't
> change.
> >
> > So there are multiple ways to do this without requiring a new interface into
> LLVM and further linking the backends and the frontend.
> > 1) Utilize the calling convention and standardize the address space mappings
> for each language. If the address space interpretation is different, a different
> calling convention is required for that backend. Say you have the OpenCL
> calling convention, the C calling convention, and the C++AMP calling
> convention. The backends that support these calling conventions then can
> interpret the address spaces defined in the calling conventions accordingly.
> 
> I don't understand why should I modify the calling convention for this purpose.
> If for my opencl C implementation I want to use the standard C calling
> convention I must be free to do this. I don't see any correlation between
> address spaces and calling convention.
[Micah Villmow] In the case of OpenCL, you can't correctly use the standard C calling convention and still be OpenCL compliant, the C calling convention is too permissive. The second you use OpenCL, you are using an OpenCL specific calling convention(Kernels can't call kernels that have local memory, kernels can't have private arguments, non-kernel functions can only be called by the device and not the host, etc...). While some backends might allow you to specify the C calling convention when using OpenCL, it is because you are encoding that OpenCL knowledge in some other way that tells the backend you really aren't using the C calling convention, but instead using the OpenCL version of the C calling convention.
> 
> > 2) Expose triples that give different address space mappings. For example,
> and AMDIL backend and the R600 backend might target the exact same chip,
> but can expose different address space mapping for different architectures or
> devices because of their output target.
> > 3) Add device specific options to enable different interpretation of the
> address spaces.
> > 4) Each backend expose their address spaces, and it is the job of the frontend
> to map the source language correctly. Queries to TargetInstrInfo could be
> added to see if two address spaces are disjoint or not.
> >
> > Out of all of them, #4 is what I think would be ideal. It allows the backend and
> the frontend to work without tight integration and already uses existing
> framework to allow things like AA to work properly.
> 
> I agree that is a matter of the frontend to specify the relationship between
> logical and physical address space. I do not agree that is the frontend that
> should apply this translation, because otherwise features the derives from
> language specification are lost in the IR and cannot be used for more
> aggressive optimization. I just want to be able to keep this logical information
> and when required get the physical properties I need following what the
> frontend has specified as mapping.
> 
> This I think is more important for scenarios where the target device has only
> the default address space. If want to target OpenCL on this device I would like
> still to optimize OpenCL code as much as I can exploiting both language and
> target features.
[Micah Villmow] If the backend supports, for example, the 4 OpenCL address spaces, then the backend should define how they are to be represented, either all as a single address space, as subsets of the default address space, as disjoint address spaces, or any other representation the backend can think of. If that is defined by the backend, the IR needs to be in that form BEFORE the backend is passed the IR. If the frontend wants to represent it as something else, and then before calling the backend, convert it to the valid representation, I have no problem with that. It should not be the backends job to do this translation, otherwise you have to teach the backend all of the valid transformations for all source languages that could possibly target the backend. It is unneeded complexity with little benefit for the backend to support this 'feature'. It is a much better solution to just have the frontend do the right thing and honor the contract that the backend defines. Just for clarity, I'm grouping all of the target independent optimizations as under the domain of the frontend. If you want to write a late optimization pass that does address space fixup, there is nothing in LLVM to stop you from doing so.

I really have no problem with the rest of your proposal as I strongly feel that better address space support is important to LLVM, only with adding complexity to the backends by attempting to dynamically determine static information.
> 
> Thanks again,
> -Michele