[LLVMdev] Address space extension

[Michele Scandale]

> [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