[cfe-dev] Address space extensions (adding type modifier keywords)

[Phil Tomson via cfe-dev]

Is there any way to get added keywords to map to these attributes? I'm just
thinking we don't want to have to have the user include a special .h file.

Phil

On Thu, Oct 13, 2016 at 11:18 PM, Daniel Marjamäki <
Daniel.Marjamaki at evidente.se> wrote:

> Hello!
>
> I am not an expert. But I think you should use address space attributes.
> This code compiles without errors:
>
> #define xstglocal  __attribute__((address_space(0)))
> #define xstgblock  __attribute__((address_space(256)))
> #define xstgglobal  __attribute__((address_space(257)))
>
> int* xstglocal  lp_i;       // Local pointer to any integer
> int* xstgblock  b_pi;       // Block pointer to any integer
> int* xstgglobal g_pi;       // Global pointer to any integer
>
> xstgglobal int* xstglocal  vp_li;   // Local pointer to global integer
> xstglocal  int* xstgblock  vp_bi;   // Block pointer to local integer
> xstgblock  int* xstgglobal vp_gi;   // Global pointer to block integer
>
> Best regards,
> Daniel Marjamäki
>
> ............................................................
> ......................................................
>
> Daniel Marjamäki Senior Engineer
>
> Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden
>
>
>
> Mobile:                 +46 (0)709 12 42 62
>
> E-mail:                 Daniel.Marjamaki <Daniel.Marjamaki at evidente.se>
> @evidente.se <Daniel.Marjamaki at evidente.se>
>
>
>
> www.evidente.se
> ------------------------------
> *From:* cfe-dev [cfe-dev-bounces at lists.llvm.org] on behalf of Phil Tomson
> via cfe-dev [cfe-dev at lists.llvm.org]
> *Sent:* 14 October 2016 03:35
> *To:* cfe-dev at lists.llvm.org
> *Subject:* [cfe-dev] Address space extensions (adding type modifier
> keywords)
>
> Our architecture has a somewhat different memory model with three
> different address spaces: local, block, global.
>
> Some time ago (prior to my involvement in our project) our address space
> extensions were added to the frontend so that we can write:
>
> volatile   int v_i;
> xstglocal  int l_i;
> xstgblock  int b_i;
> xstgglobal int g_i;
>
> volatile   int* p_vi;       // Regular pointer to volatile integer
> xstglocal  int* p_li;       // Regular pointer to local integer
> xstgblock  int* b_pi;       // Regular pointer to block integer
> xstgglobal int* g_pi;       // Regular pointer to global integer
>
> int* volatile   vp_i;       // Volatile pointer to regular integer
>
> These address space modifiers (xstglocal, xstgblock, xstgglobal) are used
> to determine which address space data is stored in. The above will compile
> just fine.
>
> However, originally this work was done for clang/llvm 3.2. After we moved
> to 3.6 we found that the following (which used to work in 3.2) no longer
> works in 3.6:
>
> int* xstglocal  lp_i;       // Local pointer to any integer
> int* xstgblock  b_pi;       // Block pointer to any integer
> int* xstgglobal g_pi;       // Global pointer to any integer
>
> xstgglobal int* xstglocal  vp_li;   // Local pointer to global integer
> xstglocal  int* xstgblock  vp_bi;   // Block pointer to local integer
> xstgblock  int* xstgglobal vp_gi;   // Global pointer to block integer
>
> These result in front end errors:
>
> issue.c:13:7: error: expected identifier or '('
> int * xstglocal  lp_i;       // Local pointer to any integer
>       ^
> issue.c:14:7: error: expected identifier or '('
> int * xstgblock  b_pi;       // Block pointer to any integer
>       ^
> issue.c:15:7: error: expected identifier or '('
> int * xstgglobal g_pi;       // Global pointer to any integer
>       ^
> issue.c:20:18: error: expected identifier or '('
> xstgglobal int * xstglocal  vp_li;   // Local pointer to global integer
>                  ^
> issue.c:21:18: error: expected identifier or '('
> xstglocal  int * xstgblock  vp_bi;   // Block pointer to local integer
>                  ^
> issue.c:22:18: error: expected identifier or '('
> xstgblock  int * xstgglobal vp_gi;   // Global pointer to block integer
>                  ^
> 6 errors generated.
>
> It looks as though these address space extension keywords were added in
> TokenKinds.def:
> // XSTG address space qualifiers
> KEYWORD(xstgglobal                  , KEYXSTG)
> KEYWORD(xstgblock                   , KEYXSTG)
> KEYWORD(xstglocal                   , KEYXSTG)
>
> As well as in Attr.td:
>
> def XSTGLocalAddressSpace : TypeAttr {
>   let Spellings = [Keyword<"xstglocal">];
>   let Documentation = [Undocumented];
> }
>
> def XSTGBlockAddressSpace : TypeAttr {
>   let Spellings = [Keyword<"xstgblock">];
>   let Documentation = [Undocumented];
> }
>
> def XSTGGlobalAddressSpace : TypeAttr {
>   let Spellings = [Keyword<"xstgglobal">];
>   let Documentation = [Undocumented];
> }
>
> with some support in ParseDecl.cpp.
>
> Was there an API change between clang 3.2 and 3.6 that might have broken
> this? Any pointers on how I might fix these errors?
>
> Thanks.
>
> Phil
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161014/61bd196b/attachment.html>