Hi Micah, On 08/10/2013 06:01 AM, Micah Villmow wrote:> Michele, > Why can not the target triple implicitly encode the address space mapping? I would not expect address spaces to map correctly if I compile OpenCL code on an AMD device and then compile the IR on an NVidia device. Even an AMD device targeted from OpenCL could have a different mapping than the same AMD device targeted from C++AMP, DirectX or OpenGL. Address space mapping should be part of the ABI definition and be part of the contract between the frontend and the backend. Adding extra information in the metadata would then be redundant.Sure the IR would have some target dependences that prevents its usage as is with another target: this is a good point I haven't taken into account. I don't like the idea to "encode" this mapping within the triple known by LLVM: this would be equivalent to make backends ware of language-specific features, like the choices of logical address space mapping done by frontends. My objection is: why if I want to use LLVM as a tool for a "new" language (a "new" frontend) that uses address spaces I should modify also LLVM to add a new triple variant to specify my mapping? I agree with you that this mapping is a "static" property of the contract between the frontend and the backend so it is confusing to put this information in the module. A solution would be something like the current "TargetTransformInfo" for represent source language details, e.g. a LanguageTransformInfo pass: this kind of pass would be registered by the frontend in building process of the compiler pipeline (the information about the mapping may be required also in the middle end indirectly, e.g. to know the bitsize of a pointer of a given logical address space). The address space map function would fit perfectly as a property for such a structure, would create a safe and static way for frontends to honoring the contract with backends. There is a big limitation: without such a pass in the compiler pipeline the correctness of code generation is not guaranteed (e.g. how can I use 'llc' without specifying this pass?). Thanks. -Michele
> -----Original Message----- > From: Michele Scandale [mailto:michele.scandale at gmail.com] > Sent: Friday, August 09, 2013 11:41 PM > To: Micah Villmow > Cc: James Courtier-Dutton; LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > Hi Micah, > > On 08/10/2013 06:01 AM, Micah Villmow wrote: > > Michele, > > Why can not the target triple implicitly encode the address space mapping? I > would not expect address spaces to map correctly if I compile OpenCL code on > an AMD device and then compile the IR on an NVidia device. Even an AMD > device targeted from OpenCL could have a different mapping than the same > AMD device targeted from C++AMP, DirectX or OpenGL. Address space > mapping should be part of the ABI definition and be part of the contract > between the frontend and the backend. Adding extra information in the > metadata would then be redundant. > > Sure the IR would have some target dependences that prevents its usage as is > with another target: this is a good point I haven't taken into account. > > I don't like the idea to "encode" this mapping within the triple known by LLVM: > this would be equivalent to make backends ware of language-specific features, > like the choices of logical address space mapping done by frontends. My > objection is: why if I want to use LLVM as a tool for a "new" language (a "new" > frontend) that uses address spaces I should modify also LLVM to add a new > triple variant to specify my mapping?[Micah Villmow] The backends won't understand your address space mapping. The backends should expose their address spaces that they support, their sizes and their overall semantics. It should be documented just like the calling convention is documented. It is then the job of the frontend to map whatever source language address spaces are used onto the correct address spaces for the target. For example, the AMDIL backend supports multiple address spaces. If your new language has more than 1 address space, then your frontend has to map them to the backend's address spaces at compile time based on the target triple. If they don't map directly, then you will have to just use the default for all of them. As someone who has written three backends, it is entirely unrealistic to expect all of the backends to support any variable address space setup. It is quite annoying and messy to deal with, as I've done it. One, although hacky, way to work around it is to have the backend support a language specific option on how to interpret address spaces.> > I agree with you that this mapping is a "static" property of the contract > between the frontend and the backend so it is confusing to put this information > in the module. > > A solution would be something like the current "TargetTransformInfo" for > represent source language details, e.g. a LanguageTransformInfo pass: > this kind of pass would be registered by the frontend in building process of the > compiler pipeline (the information about the mapping may be required also in > the middle end indirectly, e.g. to know the bitsize of a pointer of a given logical > address space). > > The address space map function would fit perfectly as a property for such a > structure, would create a safe and static way for frontends to honoring the > contract with backends. > > There is a big limitation: without such a pass in the compiler pipeline the > correctness of code generation is not guaranteed (e.g. how can I use 'llc' > without specifying this pass?). > > Thanks. > > -Michele
> [Micah Villmow] The backends won't understand your address space mapping. The backends should expose their address spaces that they support, their sizes and their overall semantics. It should be documented just like the calling convention is documented. It is then the job of the frontend to map whatever source language address spaces are used onto the correct address spaces for the target. For example, the AMDIL backend supports multiple address spaces. If your new language has more than 1 address space, then your frontend has to map them to the backend's address spaces at compile time based on the target triple. If they don't map directly, then you will have to just use the default for all of them. As someone who has written three backends, it is entirely unrealistic to expect all of the backends to support any variable address space setup. It is quite annoying and messy to deal with, as I've done it. One, although hacky, way to work around it is to have the backend supp!ort a lang uage specific option on how to interpret address spaces. Probably I haven't understood your point or I haven't been able to make my point clear. What I am saying is the the frontend must generate the correct mapping information: so the knowledge of physical address spaces must be embedded also in the frontend (as property of the target description): a given backend knows only its physical address spaces. The frontend can emit logical address spaces in the IR to improve optimizations in the middle end that may use knowledge related to the language semantic. The mapping information would be used when information about the physical location are required. This would allow the frontend to use in the IR whatever custom address space enconding to represent whatever abstract language address space, but at the same time it should provide the correct mapping on the set of address space for the destination target to ensure the correctness of the target code generation. The point is to being able to decouple logical and physical address spaces. At the end physical address spaces must be used so I have to explicit also the relationship between the two. -Michele
Michele, The information you are trying to gather is fundamentally static information, and as such can be implicit. It doesn't matter what OpenCL program you are trying to compile, the address space information for each backend doesn't change. So there are multiple ways to do this without requiring a new interface into LLVM and further linking the backends and the frontend. 1) Utilize the calling convention and standardize the address space mappings for each language. If the address space interpretation is different, a different calling convention is required for that backend. Say you have the OpenCL calling convention, the C calling convention, and the C++AMP calling convention. The backends that support these calling conventions then can interpret the address spaces defined in the calling conventions accordingly. 2) Expose triples that give different address space mappings. For example, and AMDIL backend and the R600 backend might target the exact same chip, but can expose different address space mapping for different architectures or devices because of their output target. 3) Add device specific options to enable different interpretation of the address spaces. 4) Each backend expose their address spaces, and it is the job of the frontend to map the source language correctly. Queries to TargetInstrInfo could be added to see if two address spaces are disjoint or not. Out of all of them, #4 is what I think would be ideal. It allows the backend and the frontend to work without tight integration and already uses existing framework to allow things like AA to work properly. 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 5:11 AM > To: Michele Scandale > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > > > > -----Original Message----- > > From: Michele Scandale [mailto:michele.scandale at gmail.com] > > Sent: Friday, August 09, 2013 11:41 PM > > To: Micah Villmow > > Cc: James Courtier-Dutton; LLVM Developers Mailing List > > Subject: Re: [LLVMdev] Address space extension > > > > Hi Micah, > > > > On 08/10/2013 06:01 AM, Micah Villmow wrote: > > > Michele, > > > Why can not the target triple implicitly encode the address space > > > mapping? I > > would not expect address spaces to map correctly if I compile OpenCL > > code on an AMD device and then compile the IR on an NVidia device. > > Even an AMD device targeted from OpenCL could have a different mapping > > than the same AMD device targeted from C++AMP, DirectX or OpenGL. > > Address space mapping should be part of the ABI definition and be part > > of the contract between the frontend and the backend. Adding extra > > information in the metadata would then be redundant. > > > > Sure the IR would have some target dependences that prevents its usage > > as is with another target: this is a good point I haven't taken into account. > > > > I don't like the idea to "encode" this mapping within the triple known by > LLVM: > > this would be equivalent to make backends ware of language-specific > > features, like the choices of logical address space mapping done by > > frontends. My objection is: why if I want to use LLVM as a tool for a "new" > language (a "new" > > frontend) that uses address spaces I should modify also LLVM to add a > > new triple variant to specify my mapping? > [Micah Villmow] The backends won't understand your address space mapping. > The backends should expose their address spaces that they support, their sizes > and their overall semantics. It should be documented just like the calling > convention is documented. It is then the job of the frontend to map whatever > source language address spaces are used onto the correct address spaces for > the target. For example, the AMDIL backend supports multiple address spaces. > If your new language has more than 1 address space, then your frontend has to > map them to the backend's address spaces at compile time based on the target > triple. If they don't map directly, then you will have to just use the default for > all of them. As someone who has written three backends, it is entirely > unrealistic to expect all of the backends to support any variable address space > setup. It is quite annoying and messy to deal with, as I've done it. One, although > hacky, way to work around it is to have the backend suppor! > t a language specific option on how to interpret address spaces. > > > > > I agree with you that this mapping is a "static" property of the > > contract between the frontend and the backend so it is confusing to > > put this information in the module. > > > > A solution would be something like the current "TargetTransformInfo" > > for represent source language details, e.g. a LanguageTransformInfo pass: > > this kind of pass would be registered by the frontend in building > > process of the compiler pipeline (the information about the mapping > > may be required also in the middle end indirectly, e.g. to know the > > bitsize of a pointer of a given logical address space). > > > > The address space map function would fit perfectly as a property for > > such a structure, would create a safe and static way for frontends to > > honoring the contract with backends. > > > > There is a big limitation: without such a pass in the compiler > > pipeline the correctness of code generation is not guaranteed (e.g. how can I > use 'llc' > > without specifying this pass?). > > > > Thanks. > > > > -Michele > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev