This change adds a new module, `PrintIRLocalFlow.qll`, which can be imported into any query that uses both `PrintIR.qll` and the IR dataflow library. The IR dump printed by `PrintIR.qll` will be annotated with information about how each operand and instruction participates in dataflow.
For each operand and instruction, the following propeties are displayed:
- `flow`: Which local operands/instructions have flow to this node, and which local operands/instruction this node has flow to.
- `source`: `true` if this node is a source
- `sink`: `true` if this node is a sink
- `barrier`: Lists which kinds of barrier this node is. Can be zero or more of `full`, `in`, `out`, and `guard`. If the node is a guard barrier, the IR of the guarding instruction is also printed.
We already had a way to print additional properties for instructions and blocks, but not for operands. I added support for operand properties to `IRPropertyProvider`. These are now printed in a curly-brace-enclosed list immediately after the corresponding operand.
When printing flow, instructions are identified by their result ID (e.g., `m128`). Operands are identified by both the result ID of their instruction and their kind (e.g., `r145.left`). For flow from an operand to its use instruction, it just prints `result` at the operand, and prints only the operand kind on the instruction.
Example output:
```
# 344| m344_34(vector<int, allocator<int>>) = Chi : total:m344_20{flow:def->@, @->result}, partial:m344_33{flow:def->@, @->result}
# 344| flow = total->@, partial->@, +m344_33->@, @->+r347_3, @->v347_7.side_effect, @->m347_9.total, @->m344_20.1
```
The `+` annotations indicate when the flow came from `isAdditionalFlowStep()`, rather than built-in local flow.
The number of candidate bounds during the main `SimpleRangeAnalysis`
recursion was in principle always exponential in the size of the
program, but in practice it did not get out of hand when only `+` and
`-` operations were supported. Now that `*` is also supported, the range
analysis started timing out on the SinaMostafanejad/OpenRDM project. The
problematic expressions in that project are of the form
a*x*x*x + b*x*x + c*x + d
where most of the variables involved are recursive definitions and are
therefore likely to have a large number of candidate bounds.
The fix here is to identify those few binary operations that are most
likely to cause an explosion in the number of bounds and apply widening
to them. Previously, widening was only applied at definitions.
