[cfe-dev] Address space extensions (adding type modifier keywords)
Daniel Marjamäki via cfe-dev
cfe-dev at lists.llvm.org
Fri Oct 14 23:17:47 PDT 2016
Hello!
> This doesn't seem to work for me, what version of clang are you using?
Hmm weird. I use latest svn head. I don't know if it matters but the target I'm using is Linux x64. This has worked for at least a year for me so I'd say it should work at least in Clang-3.8 also.
Also when I said "This code compiles without errors" I only meant that "clang -c myfile.c" finished without error/warning messages.
> 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.
In my use case, adding "-include tweaks.h" in the build script was an easy solution. But in my case I don't actually compile. I run static analysis and clang-tidy, and I generate compiler warnings (with -fsyntax-only)...
If you want to actually compile then tweaking Clang is required. I don't know how you map these attributes internally.
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<mailto:Daniel.Marjamaki at evidente.se>@evidente.se<mailto:Daniel.Marjamaki at evidente.se>
www.evidente.se
________________________________
From: Phil Tomson [phil.a.tomson at gmail.com]
Sent: 15 October 2016 00:18
To: Daniel Marjamäki
Subject: Re: [cfe-dev] Address space extensions (adding type modifier keywords)
This doesn't seem to work for me, what version of clang are you using?
Phil
On Thu, Oct 13, 2016 at 11:18 PM, Daniel Marjamäki <Daniel.Marjamaki at evidente.se<mailto: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<mailto:Daniel.Marjamaki at evidente.se>@evidente.se<mailto:Daniel.Marjamaki at evidente.se>
www.evidente.se<http://www.evidente.se>
________________________________
From: cfe-dev [cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>] on behalf of Phil Tomson via cfe-dev [cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>]
Sent: 14 October 2016 03:35
To: cfe-dev at lists.llvm.org<mailto: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/20161015/3717fee5/attachment.html>
More information about the cfe-dev
mailing list