[LLVMdev] Address space extension

[Micah Villmow]

> -----Original Message-----
> From: Michele Scandale [mailto:michele.scandale at gmail.com]
> Sent: Sunday, August 11, 2013 2:42 AM
> To: Micah Villmow
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Address space extension
> 
> 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!
[Micah Villmow] The queries would be for physical address spaces, not the logical ones. The logical ones are language specific and thus should not be part of the backend.
> 
> 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