Adding a new def for global keyword in

Hello Clang Developers:

I’m new to clang and I’m trying to add a “global” keyword to a new extension of C. I’ve found and I’ve been playing with it. It seems that what I want is basically the same as what is in the OpenCLGlobalAddressSpace definition:

def OpenCLGlobalAddressSpace : TypeAttr {

let Spellings = [Keyword<"__global">, Keyword<“global”>];

let Documentation = [Undocumented];


However, as you can see, OpenCL already uses “global” and the like. I had thought that just putting the TokenKinds.def options in to ensure that it only was recognized for the new language would work, but it turns out that even then, I still get an assertion error about multiple string matches if I duplicate the above using PXCGlobalAddressSpace instead. What I really want is to have the “global” keyword, when in my PXC language, to be mapped as a PXCGlobalAddressSpace, and not as an OpenCLGlobalAddressSpace. How can I do this? does not seem to support multiple definitions with the same keywords.

The attribute tablegen does have some limited support for multiple
attributes with the same spelling, however, they must be
target-specific. For instance, ARMInterrupt and MSP430Interrupt are an
example of attributes which share the same spelling, and even have
different arguments. The problem is: you can't have both OpenCL's
global keyword at the same time as yours, because there's no machinery
in place to map which one should be generated when.


Dear Aaron:

Thank you for clarifying that I can’t have a global keyword around clobbering the OpenCL global keyword. If I might ask then, what is the best way to handle this? Should I just rename OpenCLGlobalAddressSpace to GlobalAddressSpace or some such and then handle them as appropriate depending on whether I’m in one language mode or the other? Or is there some other better way of dealing with this?

Is your attribute a type attribute, or is it a declaration attribute?
If it's a type attribute and works in the same way as OpenCL's (which
is an address space attribute), you could probably just rename. If
it's significantly different from OpenCL's, you may have to implement
custom parsing logic and handle this at the parsing stage instead of
the sema stage depending on whether it's an OpenCL global or your
global. So instead of adding an attribute with a spelling, as in
Parser::ParseOpenCLQualifiers, you would create your attribute
implicitly. See Sema::AddAlignmentAttributesForRecord for an example
of how that happens. The downside to this is that the attribute isn't
really implicit, so things like pretty printing can be mucked up.


Dear Aaron:

Thanks for your clarification on handling the attribute. I don’t think I’m likely to do any custom parsing, but you’ve given me what I need to figure out how to solve this little issue. Thank you very much.