[cfe-commits] [patch] Qualifiers refactor

[Daniel Dunbar]

On Thu, Sep 24, 2009 at 12:46 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 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.

I still don't see why we need the bump. All we need is a sentinel
value to indicate that we should check for extquals, so why not only
require this check when both restrict and volatile are present. Since
restrict and volatile are unlikely to occur together, in practice this
mean should avoid wasting unnecessary memory. Although 609 is also a
very small number, so I'm not particularly concerned about it.

I mentioned this to John, who thought it added more complexity than
needed, but since I haven't actually read the patch I don't understand
why yet.

 - Daniel