* Make the following private headers public:
* Lift/CPUStateAccessAnalysisPass.h
* Lift/CSVOffsets.h
* Lift/PTCDump.h
* Lift/VariableManager.h
* Move from revngSupport to revngLift:
* IRAnnotators.{h,cpp}
* SelfReferencingDbgAnnotationWriter.{h,cpp}
* Move from revngSupport to revngModel:
* FunctionTags.{h,cpp}
* ProgramCounterHandler.{h,cpp}
* Move from revngSupport to revngRecompile:
* OriginalAssemblyAnnotationWriter.{h,cpp}
The container used to store the associated `ExprNode`s that we need to
flip when performing a `HybridNot` simplification, is changed from a
`llvm::SmallVector` to `llvm:SmallSet`.
Indeed, during the collection of the `ExprNode`s pointing to a
`llvm::BasicBlock`, it should not be possible to find a single
`ExprNode` twice. We now assert this fact.
We introduce a simplification step, which looks for `switch`es that can
be reduced to simpler `if` statements.
Specifically, the logic is the following:
1) When we identify a `switch` statement composed by a single `case` and
a possible default, we transform it into an `if` with the `case` now
corresponding to the `then`, and the `default` corresponding to the
`else`, if present.
2) When we identify a `switch` statement composed by two `case`s, and no
`default` is present, we can promote it to an `if` with `then` `else`
branches.
Other key details:
- The promotion happens only if we can identify at least one of the
`case`s that have a single element in the `case` label. If this is not
the case, we do not promote one to RHS of the `if` condition.
- A new `CompareNode` class, inheriting from `ExprNode`, is created, in
order to represent the equality or inequality condition of an `IfNode`
instance that is the result of the promotion. This `CompareNode` can
represent for the LHS both an `llvm::Value` or the `loop_state_var`,
while it embeds the RHS constant which completes the comparison.
- We remove `SwitchBreak` AST nodes that may now appear as children of
an `if` node promoted from a `switch`.
- We introduce in the `CompareNode` the `weaved` concept. Indeed, if a
promotion of a weaved `switch` happens, we should avoid the
serialization of the instructions leading to the computation of the
condition of the original `switch`, because they have been already
emitted by the main related dominating `switch`.
We also introduce an additional simplification step, which takes care
of:
- Promoting `!(==)` to `(!=)` and `!(!=)` to `(==)`, if the inner
equal/not equal is represented via a `CompareNode`.
- Promoting `x == 0` to `!x` and `x != 0` to `x`.
To be able to correctly emit (or not) the instructions computing a
condition of an `IfNode`, we need to add the `EmittBB` flag, an
additional parameter to the `buildGHASTCondition` function, which
controls the emission of the statements of a basic block computing a
condition.
Consequently, the `IfNode` acquires a `IsWeaved` field, which is used to
mirror the property having the same name on `SwitchNode`. Being now
possible a promotion from a dual `SwitchNode` to an `IfNode`, we need to
represent this property on the `IfNode` too.
Introduce the hybrid beautifier aiming to simplify double `not`s (one on
the IR side (e.g., a `icmp ne`), and one on the `ExprNode` side on the
`GHAST` in the form of a `NotNode`.
To do this hybrid beautifier, we basically need to do the following:
- Implement a preliminary collection phase which computes which
`ExprNode`s are affected by which `BasicBlock`.
- Compute the so-called consesus, i.e., verify that for all the
`ExprNode`s affected by a certain `BasicBlock`, the transformation
would be beneficial in terms of output. Basically:
1) That the number of `!(!=)` transformed into `(==)` outscores the
number of correlated `(!=)` which are transformed into `!(==)`.
2) That the number of `!(==)` transformed into `(!=)` outscores the
number of correlated `(==)` which are transformed into `!(!=)`.
- Actually perform the transformation for those situations where the
consensus agrees.
Alessandro Di Federico