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
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
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
On 08/11/2013 08:41 AM, Micah Villmow wrote:> 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.To know if two address spaces are disjoint for alias analysis purpose, it's more effective to know if in the source language the property holds or not, because as said two disjoint address spaces in the abstract model (like the one defined by OpenCL) can be implemented in the same physical address space in separated regions, so asking to the target wont produce the correct answer for all the targets (see X86 or whatever 'classical' processor with one address space)! -Michele
> -----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
> -----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.