The `InstructionSanity::duplicateOperand` predicate used `count` instead
of `strictcount`. The 0-case of this `count` was as large as the
Cartesian product of `Instruction` and `OperandTag`, which made
`duplicateOperand` take forever to compute on large snapshots.
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.
This makes two changes to how example exprs are selected. Example exprs
are now ordered separately by each piece of the location, rather than by
stringifying their location. Second, UnknownLocations are now ordered
after locations with absolute paths, by using "~" in the lexicographic
comparison of absolute paths. I think this works on both POSIX and
Windows systems, but it's possible I'm missing a way to start an
absolute path with a unicode character.
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.
