Adding a new type qualifier

Clang Frontend
#1

Hello,

I am trying to add a new qualifier to the existing clang architecture. So far I was looking into replacing one of the existing qualifiers “volatile or restrict” from the “fast qualifiers”. Now I think its a bad idea to do that. Can someone tell me

whats the best way to add a new type quailfier?
Why are there only 3 fast qualifiers added to the qualtype?
How can I increase the size of the fast qualifiers, I mean how to add new qualifier to qualtype without actually disturbing the existing fast quals : const, volatile, restrict.

I was looking into :

enum TQ { // NOTE: These flags must be kept in sync with DeclSpec::TQ.
Const = 0x1,
Restrict = 0x2,
Volatile = 0x4,

  • new_qualifier = 0x8,

  • CVRMask = Const | Volatile | Restrict | new_qualifier

};

enum {
/// The maximum supported address space number.
/// 24 bits should be enough for anyone.
MaxAddressSpace = 0xffffffu,

/// The width of the “fast” qualifier mask.

  • FastWidth = 2,
  • FastWidth = 3,

/// The fast qualifier mask.
FastMask = (1 << FastWidth) - 1
};

and working on changing the APIs of the Type.h file inside Clang/AST.
am I looking in a right direction here? can an expert give a reply.

Thanks.

#2

I am trying to add a new qualifier to the existing clang architecture. So far I was looking into replacing one of the existing qualifiers "volatile or restrict" from the "fast qualifiers". Now I think its a bad idea to do that. Can someone tell me

>> whats the best way to add a new type quailfier?

The first question you should ask yourself is whether this is really a qualifier. Does it need to apply to arbitrary types? Is it more appropriately modeled as an attribute on specific type declarations, or possibly an independent type kind? Does it behave like a normal C qualifier, e.g. it is lost during r-value conversion?

Assuming that's true, read on.

>> Why are there only 3 fast qualifiers added to the qualtype?

The fast qualifiers are mangled into the low bits of the type pointer; that's why they're fast, because they don't need to be stored separately. Other qualifiers are stored in a separately-allocated ExtQuals structure.

If we allocate Types with 8-byte alignment, we have three bits available. Currently only const and restrict are fast, and the third bit is used to indicate that the type has extended qualifiers.

>> How can I increase the size of the fast qualifiers, I mean how to add new qualifier to qualtype without actually disturbing the existing fast quals : const, volatile, restrict.

I would strongly suggest that you avoid changing the fast-qualifiers representation. Just add your new qualifier to the Qualifiers structure and make sure the Profile method includes it, and then you'll just need to worry about the N places in the code which assume they know about every qualifier (I consider such code to be buggy, but surprisingly that judgement doesn't by itself fix any bugs :slight_smile: ).

John.

#3

Thanks for the reply john. What I want is something like the _global qualifier of opencl. The hardware architecture that I am trying to support with clang has this global address space. I am not sure about how to add an address space qualifier and parse and generate IR all the way.
I looked into the embedded C “address space” type qualifier, Can an expert who is familiar with openCL, tell me if this could be changed to act like the _global type qualifier. If not, I can use some suggestions too.

The following link was posted in march about the address space qualifiers, I would like to know if there was any progress on this topic.
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-March/008252.html

Thanks a lot.

#4

Thanks for the reply john. What I want is something like the _global qualifier of opencl. The hardware architecture that I am trying to support with clang has this global address space. I am not sure about how to add an address space qualifier and parse and generate IR all the way.
I looked into the embedded C “address space” type qualifier, Can an expert who is familiar with openCL, tell me if this could be changed to act like the _global type qualifier. If not, I can use some suggestions too.

The following link was posted in march about the address space qualifiers, I would like to know if there was any progress on this topic.
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-March/008252.html

The opencl implementations that I’m familiar with handle this by making _global be a #define for attribute((address_space…

-Chris