[cfe-commits] r153898 - /cfe/trunk/include/clang/Analysis/ProgramPoint.h

[Jordan Rose]

On Apr 2, 2012, at 17:44, Benjamin Kramer wrote:

> 
> On 02.04.2012, at 23:24, Ted Kremenek wrote:
> 
>> Author: kremenek
>> Date: Mon Apr  2 16:24:13 2012
>> New Revision: 153898
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=153898&view=rev
>> Log:
>> Reduce static analyzer memory usage by about 4% by packing the ProgramPoing 'Kind' field into the spare bits of other fields.
>> 
>> Modified:
>>   cfe/trunk/include/clang/Analysis/ProgramPoint.h
>> 
>> Modified: cfe/trunk/include/clang/Analysis/ProgramPoint.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/ProgramPoint.h?rev=153898&r1=153897&r2=153898&view=diff
>> ==============================================================================
>> --- cfe/trunk/include/clang/Analysis/ProgramPoint.h (original)
>> +++ cfe/trunk/include/clang/Analysis/ProgramPoint.h Mon Apr  2 16:24:13 2012
>> @@ -55,27 +55,59 @@
>>              EpsilonKind};
>> 
>> private:
>> -  std::pair<const void *, const void *> Data;
>> -  Kind K;
>> +  std::pair<uintptr_t, const void *> Data;
>> 
>>  // The LocationContext could be NULL to allow ProgramPoint to be used in
>>  // context insensitive analysis.
>> -  const LocationContext *L;
>> +  uintptr_t L;
>>  const ProgramPointTag *Tag;
>> 
>>  ProgramPoint();
>> 
>> +  static uintptr_t mangleUpperKindBits(Kind K, const void *p) {
>> +    uintptr_t tmp = (uintptr_t) p;
>> +    uintptr_t k_int = (uintptr_t) K;
>> +    k_int >>= 3;
>> +    assert((k_int & 0x3) == k_int);
>> +    tmp |= k_int;
>> +    return tmp;
>> +  }
>> +  
>> +  static uintptr_t mangleLowerKindBits(Kind K, const void *p) {
>> +    uintptr_t tmp = (uintptr_t) p;
>> +    uintptr_t k_int = (uintptr_t) K;
>> +    k_int &= 0x7;
>> +    tmp |= k_int;
>> +    return tmp;
>> +  }
> 
> You could hide some of this nastiness by using 2 llvm::PointerIntPairs with 3 bits each.
> 
> - Ben

I'm actually wondering why we're using a std::pair at all here. It's not like it's visible outside of the implementation.

Also, I'd suggest mangling the bits into the /second/ data pointer, on the suspicion that if one of our ProgramPoint subclasses starts using a data field as a uintptr_t (or PointerIntPair), they'll probably mess with the first data pointer first. They may not even need the second pointer.

Jordy