This query gets optimized badly, and it has started timing out when we
run it on our own code base. Most of the evaluation time is spent in an
RA predicate named `#select#cpe#1#f#antijoin_rhs#1`, which takes 1m36s a
Wireshark snapshot.
This restructuring of the code makes the problematic RA predicate go
away.
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.
Instead of computing these two things in one predicate, they are
computed in separate predicates and then joined. This splits the
predicate `primitive_basic_block_member`, which took 77s before, into
predicates that together take 18s on a medium-sized db.
By extending this class, a class can define its own `getLocation`
predicate without participating in the dispatch hierarchy of
`getLocation` as defined on `Element`. Classes wanting to override their
location previously had to define `getURL` or `hasLocationInfo` instead
and rely on these predicates not being defined on future versions of
`Element`.
gmtime and gmtime_r take a time_t pointer, so have to store the value
of time(NULL) on the stack.
Signed-off-by: Ole Herman Schumacher Elgesem <oleherman93@gmail.com>
This changes the test output because `VariableDeclarationGroup.toString`
changes to be the one inherited from VariableDeclarationEntry. This
should not affect the output as shown by any front end because
the string to be displayed to the user for a `$@` interpolation comes
from the following column instead.
This avoids using a raw db type.
It is possible for `SuppressionComment` and `SuppressionScope` to have
different locations because `SuppressionScope` defines `hasLocationInfo`
as a new rootdef whereas `SuppressionComment` only responds to
`getLocation` that it inherited. In interpretation of query results, a
`hasLocationInfo` predicate is preferred over `getLocation` if it
exists.
