[LLVMdev] Address space extension

[Michele Scandale]

Hello to everybody,

I would like to start a discussion about a possible extension of address 
space concept in LLVM.

The idea was born starting from this discussion in the clang mailing 
list (first msg: 
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130715/084011.html 
- interesting point: 
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130722/084499.html) 
where the fact that "source language level" informations about address 
spaces can be useful to perform optimizations in the middle end.

IMHO this information should be a plus that could be *safely* ignored 
when not necessary and used where it can provide an improvement in 
optimizations. This does not necessary mean the the middle-end (and the 
back-ends) must be aware of the semantic of these logical address 
spaces, it would be enough just to distinguish between two logically 
different address spaces.
The first application I see is alias analysis: for targets that do not 
have different physical address spaces (e.g. X86), meaning that in the 
IR the 'addrspace' modifier *should* not be present, the knowledge that 
two pointers refers to different logical address spaces (e.g. OpenCL 
address spaces) can be used to decide the aliasing.

Currently the 'addrspace' modifier refers to target defined address 
spaces (physical address spaces), so I would like to know if this 
extension is a reasonable approach.
Otherwise changing the 'addrspace' semantic could allow an alternative 
way: the middle end would be "automatically" aware of this information 
but the address space lowering must be moved elsewhere before the 
instruction selection using some language-specific pass the produce the 
correct lowering. An issue with this approach is that the 
middle-end/back-end pipeline it will rely on a language specific pass or 
equivalent mechanism during the instruction selection.

Thanks in advance for the attention and for your future answer.

Best regards,

Michele Scandale