On a snapshot of Postgres, evaluation of
`getNextExplicitlyInitializedElementAfter#fff#antijoin_rhs#1` took
forever, preventing the computation of the IR. I haven't been able to
reproduce it with a small test case, but the implementation of
`getNextExplicitlyInitializedElementAfter` was fragile because it called
the inline predicate `ArrayAggregateLiteral.isInitialized`. It also
seemed inefficient that `getNextExplicitlyInitializedElementAfter` was
computed for many values of its parameters that were never needed by the
caller.
This commit replaces `getNextExplicitlyInitializedElementAfter` with a
new predicate named `getEndOfValueInitializedRange`, which should have
the same behavior but a more efficient implementation. It uses a helper
predicate `getNextExplicitlyInitializedElementAfter`, which shares its
name with the now-deleted predicate but has behavior that I think
matches the name.
The overrides of `Instruction.getOperandMemoryAccess` did not relate
`this` to any of its other parameters, which made it attempt to compute
the Cartesian product of `Instruction` and `TPhiOperand`. This happened
only during computation of aliased SSA. Perhaps the optimizer was able
to eliminate the CP for the non-aliased SSA computation.
With this change, I'm able to compute aliased SSA for medium-sized
snapshots.
Instead of computing these two things in one predicate, they are
computed in separate predicates and then joined. This splits the
predicate `getInstruction`, which took 81s before, into predicates that
together take 20s on a medium-sized db.
Moved IR flavors into "implementation", with internal files under "implementation/internal". Made `IRBlockConstruction` just a nested module of `IRConstruction`/`SSAConstruction`, so it gets picked up from the `Construction` parameter of the `IR` module, rather than being picked up just from being in the same directory as `IRBlock`.
This change makes the public IR.qll module resolve to the flavor of the IR that we want queries to use. Today, this is the aliased SSA flavor of the IR. Should we add additional IR iterations in the future, we'll update IR.qll to resolve to whichever one we consider the default.
I moved the PrintIR.ql and IRSanity.ql queries into the internal directories of the corresponding flavors. There's still a PrintIR.ql and an IRSanity.ql in the public IR directory, which use the same IR flavor as the public IR.qll.
There are no real code changes here, other than to fix up `import`s. All tests still hae the same output, as expected.
A future commit will hide the IR flavors other than the one we want queries to use directly.
