[LLVMdev] Address space extension
Michele Scandale
michele.scandale at gmail.com
Sat Aug 10 04:59:51 PDT 2013
Hi Sergey,
On 08/10/2013 12:29 PM, Sergey Yakoushkin wrote:
> 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.
>
I've quickly read the document... about the nesting of overlap I don't
see any problem, there are also constraints relative to the form of
overlapping (two AS can be disjoint, equivalent or subset... pure
intersection is not allowed).
The part related of address space linked to device-driver memory, IMO is
something that the frontend must fully lower to function calls whose
name must be provided by the registration mechanism of the address
space: so nothing relevant to the IR would be here.
The remaining address spaces (they will be a subset of what in that
document is named intrinsic address space) should be the one that the
target (the backend of the compiler) knows: so this informations should
be also in the frontend to ensure a correct behavior in the backend. I
think such address spaces can be handled by the address_space attribute
supported by clang now as internal mechanism.
Maybe (or probably) I am missing something...
Thanks.
-Michele
More information about the llvm-dev
mailing list