Not every case can benefit from extra liniency, so they were manually
reviewed on a case by case basis.
Additionally, this drops a couple of "this should be a non-strict
specialization" commits, because of a bug with clang
(see the GenericGraph concepts rework commit for more details) as
to avoid confusion (we wouldn't want anyone trying to solve these
"todo"s) until the clang struct type deduction is fixed. Especially
considering that there are currently no cases where these softer
versions would be beneficial (we never inherit from templates in
question).
`ValueMaterializer` is a rewrite of what was called `AdvancedValueInfo`
which follows the same principles.
The main benefits over the old version is:
* We materialize the data-flow graph and the CFG of the relevant part of
root. This makes debugging significantly easier.
* We drop the old MonotoneFramework infrastructure in favor of
getMaximalFixedPoint.
* We significantly reduce the amount of queries we make to
AdvancedValueInfo.
By using this class we can create ptml::Tags without
XML tags. It is useful in the revng-c part when we
want to generate Plain C. All PTML Tags, from now on,
should be created via this class only.
In addition, port `Yield` library to be using this.
This also reorders the enum, because when two tags collide (they have
the same `from` and `to` points, they are sorted based on the enum
values.
The new order ensures that the values we are more likely to choose
to preserve are closer to the bottom. Since each token can only have one
type associated with it, we choose the lowest one by default.
I found that it leads to better looking code when the check of whether
the range in question even has enough elements to skip is inside
the helper.
As such a separate type of skip entry point was introduced: one that
allows to iterate over the container pairwise
Now, instead of asserting, the loop just does nothing in cases like
```cpp
for (const auto &Element : zip_pairs(make_empty_range())
do_stuff();
```
`IsDynamicallyCalledFrom` is removed in favour of `IsCalledFrom`.
Looking at just how similar the actual uses of both are, there's not
much reason to keep them separate.
This is done mainly so that downstream passes do not need to run
`CollectCFG` to store information that has already been computed but not
serialized.
This come at the cost of computing the CFG also of functions we don't
want to analyze in `DetectABI`.
This commit ensure the BaseAddress is propagate as appropriate to all
levels of the importers and that it is ignored for executables
(non-PIC).
This was a recurring source of importing the same function twice, once
relocated, once not.
Ivan Krysak