If we find values to be used outside their scope, we need to always
mark them for assignment, so that they have a dedicated variable that
is declared in the right scope. To do this we:
1. Export the logic that decides if a value needs a top-scope variable
in a public header, to be used by both `VariableScopeAnalysis` and
`MarkAssignments`.
2. Add the `HasUsesOutsideBB` reason for assignment markers
Add `ReadsMemory` and `WritesMemory` Tags and restructure the
logic that decides whether two instructions are interfering
as follows:
1. Consider `Store`s and anything with a `WritesMemory` tag as
having side effects
2. Consider all the `TaintSet` of an instruction when deciding
if two instructions interfere
3. Consider both `ReadsMemory` and `WritesMemory` Tags when
deciding interference
We need to prevent stub kinds used just to represent dead elements to be
displayed in the GUI and CL.
We do so by introducing a DeadKind which expands their targets to the
empty list.
A simple pass that maps LLVM IR instructions to C operators,
taking into account their precedence and associativity to
emit nice-looking parenthesized expressions.
A pass that strips the casts off from some instructions, including
`ModelGEP`s, general function calls, return and store ones, and
embeds the cast into new dedicated `ModelCast` function calls.
When creating the DLA graph, we want to avoid inserting `instanceOf`
edges with huge offsets, so we set a limit to 64K.
This is a workaround to handle cases in which we make wrong decisions
about the base address of a SCEV expression. One of the situations in
which this occurs are expressions such as `&val + BIG_CONST`, for which
we always identify `%val` as the address and `BIG_CONST` as the offset.
When fixing this case, we should still verify that this never happens.
Calls to `OpaqueExtractValue()` are meant to replace `extractvalue`s
found in the LLVM IR. Since the type of an `OpaqueExtractValue` is
identified by both the return type (extracted value) and the first
argument's type (aggregate operand of the `extractvalue` instruction),
we need to consider both when building the associated FunctionPool.
Previously, we were identifying each `OpaqueExtractValue` variant using
only the returned value, which was wrong. In fact, if we have two
`extractvalue` instructions that extract a value of the same type
(e.g. i32) from two different aggregate types (e.g. structA and
structB), we have to define two different `OpaqueExtractValue`: one
that returns an i32 and has a parameter of type structA, and one that
returns an i32 and has a parameter of structB. If we use only the
return type, we are not able to distinguish the two.
This commit adds the newly implemented functionality in PipelineC both
in revng.api and the graphql api, allowing:
* retrieval of global variable names
* unwrapping of a single target
* execution of analyses
Moving it was causing the address of the model to change, while for the
functionality of revng-pipeline we need it to be stable.
So we pay the price of expensive copy, for the sake of downstream
stability.
The copy of a TupleTree is potentially very expensive, so it was
disabled until now and only allowed via the explict method clone().
We have now decided to make TupleTree copiable.
This commit adds a copy-constructor and a copy-assignment, killing the
clone() method that was already unused and is now effectively useless.
This commit introduces a reusable function to compact
pipeline::TargetLists that represent functions.
Initially this reasoning was only needed by TaggedFunctionKind, but now
also FunctionStringMap needs it, and potentially others in the future,
so it makes sense to keep only a single implementation for it instead of
duplicating code (and likely bugs).
Alvise de Faveri