On Thu, Aug 8, 2013 at 1:26 PM, Michele Scandale <michele.scandale at gmail.com> wrote:> On 08/08/2013 09:59 PM, Eric Christopher wrote: >> >> I don't believe so, no. Metadata should not be required for correct >> program behavior. It can be necessary for fast program behavior, but >> not for correct. The IR level handles the proper semantics of the >> program, metadata can provide extra optimization information. As an >> example see the TBAA work that was done. >> >> -eric > > > Perfectly fine with this. My question was ignoring the implementation detail > (the use of metadata to represent mapping infos). > > I think that the mapping should be a requirement for the correctness, so I > think we need another way to represent this... > > What is your opinion on this? >Wish I had one here. I completely defer to Chris for any IR design issues here. I just wanted to make sure that you didn't waste time going down the metadata for correctness path. :) -eric
On 08/08/2013 10:29 PM, Eric Christopher wrote:> Wish I had one here. I completely defer to Chris for any IR design > issues here. I just wanted to make sure that you didn't waste time > going down the metadata for correctness path. :) > > -eric >Totally agree about avoiding the waste of time. My initial idea was totally different (I was thinking to encode both logical and physical address space info in the type system), but that's why I started the discussion, to have other opinions and understand if there are better alternatives to solve the problem. Thanks for your contribution. -Michele
On 8 August 2013 21:29, Eric Christopher <echristo at gmail.com> wrote:> On Thu, Aug 8, 2013 at 1:26 PM, Michele Scandale > <michele.scandale at gmail.com> wrote: >> On 08/08/2013 09:59 PM, Eric Christopher wrote: >>> >>> I don't believe so, no. Metadata should not be required for correct >>> program behavior. It can be necessary for fast program behavior, but >>> not for correct. The IR level handles the proper semantics of the >>> program, metadata can provide extra optimization information. As an >>> example see the TBAA work that was done. >>> >>> -eric >> >> >> Perfectly fine with this. My question was ignoring the implementation detail >> (the use of metadata to represent mapping infos). >> >> I think that the mapping should be a requirement for the correctness, so I >> think we need another way to represent this... >> >> What is your opinion on this? >> > > Wish I had one here. I completely defer to Chris for any IR design > issues here. I just wanted to make sure that you didn't waste time > going down the metadata for correctness path. :) >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. 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). This also might help, by allowing target specific master description to be located in just one place, and all components, CLANG and LLVM use that information. James
On 08/08/2013 10:29 PM, Eric Christopher wrote:> On Thu, Aug 8, 2013 at 1:26 PM, Michele Scandale > <michele.scandale at gmail.com> wrote: >> On 08/08/2013 09:59 PM, Eric Christopher wrote: >>> >>> I don't believe so, no. Metadata should not be required for correct >>> program behavior. It can be necessary for fast program behavior, but >>> not for correct. The IR level handles the proper semantics of the >>> program, metadata can provide extra optimization information. As an >>> example see the TBAA work that was done. >>> >>> -eric >> >> >> Perfectly fine with this. My question was ignoring the implementation detail >> (the use of metadata to represent mapping infos). >> >> I think that the mapping should be a requirement for the correctness, so I >> think we need another way to represent this... >> >> What is your opinion on this? >> > > Wish I had one here. I completely defer to Chris for any IR design > issues here. I just wanted to make sure that you didn't waste time > going down the metadata for correctness path. :) > > -eric >The only solution I currently see without any modification to the type system is to have something like the target datalayout string. A verification pass will run at the begin of backend pipeline after IRPasses and should check using target information if the mapping is consistent. A mapping is consistent if no "illegal" address spaces should be in the map. A physical address space is considered legal or not querying target information. If no information are provided in the module, by default the mapping function is the identity. This will allow to implement raw numeric address space (like address_space attribute in clang). The verification pass delegate each target to check translated address space validity. Indeed, being the verification explicit and customizable, backends could implement their own policy and frontends could customize the address space semantic without breaking backends preconditions. I know that using something similar to the datalayout string instead of metadata is just a change of representation, but it will allow to keep the fact that correctness should not depend on metadata. Could it be a valid solution? What do you think about this? Thanks in advance. -Michele
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