[clang] [clang][NFC] Increase NumStmtBits by 2 as we are approaching the limit (PR #120341)

[John McCall via cfe-commits]

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