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


_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to