rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land.
In https://reviews.llvm.org/D52268#1241793, @riccibruno wrote: > In https://reviews.llvm.org/D52268#1241033, @rjmccall wrote: > > > `LinkageComputer` isn't actually persisted anywhere, right? And there's > > maybe one computer active at once? So this compression is theoretically > > saving one pointer of stack space but forcing a bunch of bit-manipulation > > every time these fields are accessed. > > > It is not persisted but this saves one pointer per entry in the map. Another > factor is that hashing a pair involves hashing > each component and then combining the result, which is comparatively much > more expansive than just hashing a `PointerIntPair`, > which involves only a shift and a xor. The field storing the > `LVComputationKind` is never directly read but only used to differentiate > various kinds of computations in the map. I went back and instrumented the > lookup function `LinkageComputer::lookup` with `rdtsc`, > and (with all the usual caveats about microbenchmarks and `rdtsc`) I get > that this cuts the number of ticks spent inside `lookup` > from about 8e6 to 3.5e6. Now of course taking a step back this represent > only milliseconds and is firmly in the category of > "way to small to bother", but now we might as well do it. Oh, I see, the commit summary is wrong. You're not compressing `LinkageComputer`, you're compressing a lookup key type. LGTM. Repository: rC Clang https://reviews.llvm.org/D52268 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
