[LLVMdev] Address space extension

[Micah Villmow]

Shortening the email chain.
> Using this example or another equivalent example can you explain me what is
> your variant of the solution? How would you solve the current absence of
> information in the case of X86 target?
[Micah Villmow] I understand what you are trying to do. I don't see the need, only added complexity for little gain, to involve the backends. Everything you are proposing can be done in the target independent manner. Once the code hits the backend, the code needs to be in the form the backend defines as valid. If the backend does not support multiple address spaces, then the IR should not have multiple address spaces in it. There is nothing stopping you from creating a frontend that generates the IR you want for an X86 target, but once that IR is passed to the backend, it needs to conform to the backends address spaces.
Once you require the backend to support a non-physical address space, it has to then support all of them. You can either write the conversion from logical to the physical in a single IR to IR conversion phase, or during type legalization, but either way it must be done before instruction selection. In either case, the information is static and doesn't need any encoding in the module. 
Let me put it this way, every address space that makes it past type legalization increases the ALL of the memory operations by a multiple of the number of address spaces that need to be supported. OpenCL support for your proposal would increase it by a factor of 4. If a different language with 5 different address spaces showed up, it would add another set of memory operations that have to be supported, and these 5 could have different semantics than the OpenCL 4. Last I checked, the OpenCL address spaces were not defined in the spec(SPIR partially solves this), so the semantics of each address space are different on a per vendor level. The backend would have to understand that on Vendor A, address space 1 is 'global', but on Vendor B, it is 'Constant' and on Vendor C, it is 'Local'. The AMDIL backend had to do just this(OpenCL on Mac used different encodings than OpenCL on Linux/Win), it is a royal pain to deal with. Then let us say that you want to support C++AMP, then you just doubled your problem size. DirectX and OpenGL and their address spaces? Doubled it again. Add in a few more DSL's and the problem quickly becomes unmanageable.

I've already given other solutions I would use.  Encode the IR how you want, use TBAA and provide a TII hook to see if two address spaces are disjoint or not, and then convert the IR to valid IR for the respective backends. It provides almost no backend complexity and you get what you want at the IR level.

Micah
> 
> Thanks again.
> 
> Regards,
> -Michele