r221933 - Objective-C. Fixes a regression caused by implementation

[Nico Weber]

On Thu, Dec 25, 2014 at 10:41 PM, Nico Weber <thakis at chromium.org> wrote:

> On Thu, Nov 13, 2014 at 3:37 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com>
> wrote:
>
>>
>> On Nov 13, 2014, at 2:27 PM, Fariborz Jahanian <fjahanian at apple.com>
>> wrote:
>>
>> /// ObjCMethodList - a linked list of methods with different signatures.
>> struct ObjCMethodList {
>>   ObjCMethodDecl *Method;
>> +  /// \brief count of methods with same signature.
>> +  unsigned Count;
>>   /// \brief The next list object and 2 bits for extra info.
>>   llvm::PointerIntPair<ObjCMethodList *, 2> NextAndExtraBits;
>>
>> -  ObjCMethodList() : Method(nullptr) { }
>> -  ObjCMethodList(ObjCMethodDecl *M, ObjCMethodList *C)
>> -    : Method(M), NextAndExtraBits(C, 0) { }
>> +  ObjCMethodList() : Method(nullptr), Count(0) { }
>> +  ObjCMethodList(ObjCMethodDecl *M, unsigned count, ObjCMethodList *C)
>> +    : Method(M), Count(count), NextAndExtraBits(C, 0) { }
>>
>>   ObjCMethodList *getNext() const { return NextAndExtraBits.getPointer();
>> }
>>   unsigned getBits() const { return NextAndExtraBits.getInt(); }
>>
>>
>> Since we only care about whether there are multiple methods or a single
>> method, and don’t care about the exact count, how about use a bit from
>> ‘NextAndExtraBits' to indicate if it is a single method or not, and save
>> space ?
>>
>> So something like:
>>
>>   llvm::PointerIntPair<ObjCMethodList *, 3> NextAndExtraBits;
>>   bool isSingle() const { <bit stuff> }
>>
>
> I tried to look at this as part of PR21587. From what I understand, it
> requires providing a specialization of PointerLikeTypeTraits
> for ObjCMethodList that sets NumLowBitsAvailable to 3, and making sure
> that ObjCMethodLists are always aligned (at least) to 8 byte boundaries.
> ObjCMethodList are either allocated from a bump ptr allocator or by a
> DenseMap storing pair<ObjCMethodList, ObjCMethodList> as values and
> Selectors as keys. I can pass an explicit alignment to the bump ptr
> allocator, but how can I convince the DenseMap to allocate ObjCMethodLists
> at 8 byte boundaries? On 32-bit systems, Selector will be 4 bytes and I
> think DenseMap stores keys and values in pairs, so I think the first
> ObjCMethodList in the DenseMap's value will likely not be on an 8-byte
> boundary in practice (since a table buckets is a 4-byte selector plus 2
> 8-byte ObjCMethodList and there's a bunch of them contiguously in memory).
> So there'd have to be 4 bytes of padding after the key.
>

On second thought the struct has another pointer, so we can just use one
bit from there instead. I did that in r224876.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141226/d8de99ce/attachment.html>