[LLVMdev] Address space extension

[Michele Scandale]

On 08/11/2013 08:13 AM, Micah Villmow wrote:
> 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. 


No I don't think so, during type legalization the using the function map I will
always make choice based on physical address spaces. The complexity in the
backend would be only the usage of the map. It may be that this conversion would
happen in the SelectionDAGBuilder to minimize the programming effort and only
few adjustment to ensure the logical information remains accessible also after ISel.

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

That's the major point. Without putting in the IR the map I cannot decouple
backend from frontend.

Using an incremental approach, would be fine to start modifying the IR part and
introducing the IR-to-IR transformation that lower logical address spaces to
physicals to leave the code generator part as is.
Still I cannot accept an hard-coded mapping in the backend language specific
because the implementation of new out-of-tree frontends would require
modfications in the various backends. As every library, it would be better to
use them as-is without any internal modification, otherwise also the library
must be maintained!

Adding a way for the frontend to fix at runtime its map is fine. The fact that
this must be put also in the IR is for independent tools (opt, llc, etc) in the
same way as target triple and datalayout strings.

It's crazy to harcode language specific knowledge in the backend: a backend is a
"blackbox" that takes as input the IR (it doesn't matter from which source
language has been generated) and produces object code: the source language
should not be inside any backend concept.
For almost the same reason also the middle-end should not have harcoded language
specific knowledge: the compiler driver may add directly a language specific
pass in the pipeline to solve the problem, but any other independent tool wont
be able to do its job correctly. IMO also this aspect is important because from
my personal experience these tools are essential for testing, experimenting and
debugging.

Thanks,

-Michele