[LLVMdev] Address space extension

[Michele Scandale]

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.

> 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.

Thanks again,
-Michele