[PATCH] D52268: [AST] Squeeze some bits in LinkageComputer
John McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Sep 21 10:59:47 PDT 2018
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
More information about the cfe-commits
mailing list