[LLVMdev] Address space extension
Michele Scandale
michele.scandale at gmail.com
Wed Aug 7 13:52:10 PDT 2013
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
More information about the llvm-dev
mailing list