Hello James, I've some doubts about what you are proposing...> A suggestion: > Define/describe each address space in the lower layer of LLVM. <- all > the target specific info. > E.g. Address space 0 is 64bits and needs specific instructions to access it. > The LLVM IR can query the lower layer when it needs to know a > description of address space 0 during an optimization step. > CLANG then queries LLVM for address space description when it needs it. > From the description, LLVM IR or CLANG then make their own choices: > E.g. CLANG decides for itself if, based on the address space > description, address space 0 is local, private or global. > The description of each address space would need to cover all the > different types of address space there are in enough detail. I.e. Not > just the bitsize, but also whether pointers can be converted from one > address space to another or not, and if so, how.What if a target have only *one address space*? How in the IR I can distinguish two logical address spaces if the query result is just one? What if there are no objective informations useful to make a choice? What if the desired behavior is *just a choice*? These descriptions should be language independent, otherwise it would be fine just to encode a static mapping. Indeed for the optimization, the high level semantic is what we want to describe too, e.g OpenCL disjoint address spaces mey be mapped to the same physical address space, but still they are disjoint! We would need a query system from LLVM to CLANG.> One advantage of this approach is that the "CLANG deciding for itself > whether address space 0 is local, private or global" only needs to > happen once, instead of needing to process it every time the metadata > appears (if it was stored in metadata instead).The mapping should be encoded in clang, so it's static and it would be just a table. Metadata would be emitted by clang in order to allow the middle end and the backend to do correctly their job. Thanks for your future reply. -Michele
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. Micah> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Michele Scandale > Sent: Friday, August 09, 2013 9:42 AM > To: James Courtier-Dutton > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > Hello James, > > I've some doubts about what you are proposing... > > > A suggestion: > > Define/describe each address space in the lower layer of LLVM. <- all > > the target specific info. > > E.g. Address space 0 is 64bits and needs specific instructions to access it. > > The LLVM IR can query the lower layer when it needs to know a > > description of address space 0 during an optimization step. > > CLANG then queries LLVM for address space description when it needs it. > > From the description, LLVM IR or CLANG then make their own choices: > > E.g. CLANG decides for itself if, based on the address space > > description, address space 0 is local, private or global. > > The description of each address space would need to cover all the > > different types of address space there are in enough detail. I.e. Not > > just the bitsize, but also whether pointers can be converted from one > > address space to another or not, and if so, how. > > What if a target have only *one address space*? How in the IR I can > distinguish two logical address spaces if the query result is just one? > > What if there are no objective informations useful to make a choice? > > What if the desired behavior is *just a choice*? > > These descriptions should be language independent, otherwise it would be > fine just to encode a static mapping. > > Indeed for the optimization, the high level semantic is what we want to > describe too, e.g OpenCL disjoint address spaces mey be mapped to the > same physical address space, but still they are disjoint! We would need a > query system from LLVM to CLANG. > > > One advantage of this approach is that the "CLANG deciding for itself > > whether address space 0 is local, private or global" only needs to > > happen once, instead of needing to process it every time the metadata > > appears (if it was stored in metadata instead). > > The mapping should be encoded in clang, so it's static and it would be just a > table. Metadata would be emitted by clang in order to allow the middle end > and the backend to do correctly their job. > > Thanks for your future reply. > > -Michele > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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