[LLVMdev] Address space extension

[Micah Villmow]

How about this as a solution.

Add one hook into TargetInstrInfo, and one into TargetISelLowering.

1) getAddressSpaceRelation(unsigned AS1, unsigned AS2) - Returns either disjoint, subset, superset, equal. Function defaults to equal.
2) isAddressSpaceSupported(unsigned AS) - Returns true if supported, false otherwise. Function defaults to false for all non-zero AS.

These could be used by IR passes to optimized(#1) and legalization(#2). It requires no changes by backends that do not want to support multiple address spaces and extremely minimal and reasonable support by backends that do. On a plus side, it also requires no IR/Module changes.

Micah


> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
> Behalf Of Micah Villmow
> Sent: Saturday, August 10, 2013 11:13 PM
> To: Michele Scandale
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Address space extension
> 
> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev