[LLVMdev] Address space extension

[Michele Scandale]

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?

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