All three `IRBlock.qll` files are now identical again, and they are just
a thin object-oriented layer on top of the three
`IRBlockConstruction.qll` files, two of which are identical.
As the queries live here, it makes sense for the suites to be versioned
together with them. The LGTM suite has already been moved. This commit
moves the actively-maintained non-LGTM suites.
Previously, we would try to find an element enclosing each macro
access. This is not in general well-defined, especially in the
context of template instantiations -- macros are a lexing-time
concept, and don't map cleanly onto AST elements.
`IRBlock` contains a few expensive predicates, mostly `getInstruction`
and `immediatelyDominates`. These were previously recomputed for each of
the three SSA layers even though they essentially produce the same
result in each layer. The only difference between the three types of
`IRBlock` is the phi nodes.
This commit changes the representation of `IRBlock` for `ssa` and
`aliased_ssa` so they become just wrappers around the `IRBlock` of their
previous layer. Most predicates in later layers are then computed from
the corresponding predicate of the preceding layer.
The `SSAConstruction::Cached::getInstructionOperand` predicate took
1m27s on a postgres snapshot before this change and was the slowest
predicate in SSAIR. It now takes 4.5s.
The slowdown was caused by its use of
`getUnmodeledDefinitionInstruction`, which got inlined into a place
where join orderer had little choice but to join the `MkInstruction`
relation with itself, creating a large intermediate relation.
I've added `pragma[noinline]` to `getUnmodeledDefinitionInstruction` and
also to similar predicates that are likely to cause the same problem in
the future.
Before this PR, the caching and computation of `IRBlock` spanned three
cache stages and was also separate from `SSAConstruction` even though it
shared some computations with it. They are now all cached together, so
the number of stages is reduced by 2 for each layer of IR.
I made the choice of what to cache be similar to what we do for
`PrimitiveBasicBlock` as I've recently benchmarked this and found it to
be a good choice.
