[cfe-commits] [patch] Qualifiers refactor

[Douglas Gregor]

On Sep 24, 2009, at 12:04 PM, John McCall wrote:

> Douglas Gregor wrote:
>> On Sep 23, 2009, at 2:04 AM, John McCall wrote:
>>> This could be avoided by using 16-byte alignment on Types, which
>>> would be extremely straightforward to do under the patch (modulo any
>>> possible required changes to the allocator, which I haven't
>>> investigated).
>>>
>>> This patch also audits many of the uses of qualifiers in clang,
>>> adjusting them to handle arbitrary qualifiers (or be augmentable for
>>> future qualifiers) when that was reasonably straightforward.
>>
>> I think this patch is great. The one downside I see is that it causes
>> Clang -fparse-only on Cocoa.h (from a token cache) to run about 4%
>> slower (#'s at the end). However, I'm willing to pay that cost to get
>> the API improvements this patch brings.
>
> Presumably that's with the errant debugging statements removed. :)

No, no, I figured I'd penalize you for the spurious I/O :D

> That's actually many more volatiles in the system headers than I was
> expecting.  It really might be worthwhile to grab that extra bit if
> we're going to see so many volatiles.

Let's do a separate experiment bumping up the alignment to 16, to see  
what the performance vs. memory trade-off  is.

>> Looking at the template argument deduction code, I thought of an
>> amusing case that we don't need to support (but might be a little
>> harder now):
>>
>>    template<typename T>
>>    struct address_space_of {
>>        static const unsigned value = 0;
>>    };
>>
>>    template<typename T, unsigned N>
>>    struct address_space_of<T * __attribute__((address_space(N))> {
>>        static const unsigned value = N;
>>    };
>>
>> Don't worry about this case now, of course.
>
> Yeah, I've actually been considering that possibility;  I have no idea
> how to resolve it.  Dependent attributes would be an entirely new  
> thing,
> I think.

Well, we have DependentSizedExtVectorType, which services a similar  
purpose for the ext_vector_type attribute. We could probably do the  
same thing with an DependentAddressSpaceQualifiedType that is always  
dependent (and, therefore, doesn't end up getting type-checked at all).

> It'd probably be extremely useful to people doing C++ embedded work,
> although that might be a vanishingly small set of people.


When they come knocking, we can deal with it [*].

	- Doug

[*] But, first, they have to promise to use namespaces.