> [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
> -----Original Message----- > From: Michele Scandale [mailto:michele.scandale at gmail.com] > Sent: Saturday, August 10, 2013 5:30 AM > To: Micah Villmow > Cc: James Courtier-Dutton; LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > > [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 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.[Micah Villmow] Yes, I understand this point. However, this doesn't, and shouldn't, require the backend to be involved. When you know your target device, you know the address space mapping. If you want to use different address space mappings, then it is the job of your frontend to clean it up, not the backend. Changing address spaces also isn't clean in LLVM because the type system is supposed to be constant, once a type is created, it shouldn't change. However, with your approach you are suggesting, by changing the address space after some point in the optimization stage, you are making it mutable. This can cause all sorts of nasty behavior and you pretty much need to invalidate and rerun all your analysis passes.> > -Michele
> [Micah Villmow] Yes, I understand this point. However, this doesn't, and shouldn't, require the backend to be involved. When you know your target device, you know the address space mapping. If you want to use different address space mappings, then it is the job of your frontend to clean it up, not the backend. Changing address spaces also isn't clean in LLVM because the type system is supposed to be constant, once a type is created, it shouldn't change. However, with your approach you are suggesting, by changing the address space after some point in the optimization stage, you are making it mutable. This can cause all sorts of nasty behavior and you pretty much need to invalidate and rerun all your analysis passes.My usual example: my backend supports only the default address space (AS0). How I can represent opencl_local, opencl_global, opencl_constant so that in the IR I can do optimizations that exploits the knowledge of disjointness of these logical address spaces if the frontend maps (as happens now in clang) everything to AS0? Why I should cheat in the frontend saying that my target support different address spaces (just to have the address space informations in the IR) without having an explicit mechanism to honor the fact my backend understand only physical AS0? I never said that at some point I change address spaces. I said that the mapping will happen in the instruction selection, where to pick the correct target instruction I may need to know the physical address spaces associated to a given logical address space. The instruction selection in this way is able to do its job correctly and it can preserve both logical and physical information for further optimization (like machine instr scheduling or machine LICM). During middle-end optimization information about the physical address space may be required, e.g. the pointer bitsize, but *no change will happen*! *Logical address spaces are totally independent from physical address spaces: but to realize an implementation a mapping must be performed.* Now the mapping is done by clang directly converting logical to physical address space so that in the IR all logical information are lost (especially for those targets where the translation map is trivial!). I can map the opencl_constant address space to a non-constant address space, but still I would like to use the fact that the semantic at language level allow me to optimize this. For GPU targets problems are fewer because different physical address spaces are supported. Looking only to these specific cases wont produce any general solution. -Michele