rjmccall wrote:
> FYI it looks like this has a fairly large impact on compile-time, esp at `O0`
> with a clang host compiler
> (https://llvm-compile-time-tracker.com/compare.php?from=1fcb6a9754a8db057e18f629cb90011b638901e7&to=4797437463e63ee289a1ff1904cfb7b2fe6cb4c2&stat=instructions%3Au).
>
> I wonder whether this is due to some increase in structure sizes, or because
> the choice of a non power of two bitwidth makes the accesses to the field
> inefficient.
It probably is the bit-width not matching a native integer size. If we want to
get that back, we'll need to Huffman-encode `StmtKind` — not actual Huffman
encoding, of course, but making a `BasicStmtKind` that includes our favorite
255 node kinds ("common nodes") and then making the last basic kind cover all
the uncommon kinds with some secondary extended-kind field (probably also
8-bit?). This would generalize in the future if necessary, in that we could
carve out more values out of BasicStmtKind if we needed more than 511 nodes.
Computing the actual `StmtKind` would become more expensive, essentially this:
```cxx
auto kind = node->basicKind; // 8-bit load
if (kind == 255)
kind += node->extendedKind; // 8-bit load
```
But `isa`/`dyn_cast` checks for common nodes would only need to load the basic
kind. And we could make sure that `StmtVisitor` et al. also privilege common
nodes, like by switching on the basic kind and then switching on the extended
kind in `case 255` instead of computing the full `StmtKind` up front and then
doing a single switch.
We should be able to make `ClangASTNodesEmitter` generate all of the code for
us. The emitter would require uncommon nodes to be marked in `StmtNodes.td` and
check that there aren't too many common nodes. We'd probably want it to start
synthesizing `classof` implementations, too, but that's pretty straightforward
and would remove some boilerplate from the AST headers. (The compiler would
still see it, so it's not a compile-time win for processing the header, just a
programmer burden removed.)
https://github.com/llvm/llvm-project/pull/120341
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
