[LLVMdev] Address space extension

[Sergey Yakoushkin]

Hi Michele,

Are you considering nested address spaces?

Apart from OpenCL, named address spaces have been proposed in scope of
"Embedded C" draft N1275 (2007).
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf

--> Section 5.2: Named address spaces and named-register storage classes

Summarizing, address spaces may overlap in a nested fashion. Typically
their names are intrinsic identifiers (e.g. "_x int t;" ) predefined at the
start of translation unit,
but draft also mentions optional support for user-defined address spaces.



On Thu, Aug 8, 2013 at 12:52 AM, Michele Scandale <
michele.scandale at gmail.com> wrote:

> 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<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<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
> ______________________________**_________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130810/6cd0bcaf/attachment.html>