[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.
> [Micah Villmow] The problem comes in that if you use different address space than what the backend supports and you use metadata to map from logical to physical, you now require that metadata for a correct program. You can encode source language properties with metadata(see TBAA), but the IR itself still needs to be valid without that information. The hooks to the backend can give you information on the physical address spaces, the metadata can be used to annotate source information, but the IR itself has to still be valid for the backend.