Both suggestions sound reasonable to me. On Apr 2, 2012, at 6:41 PM, Jordan Rose <[email protected]> wrote:
> > 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
