Add another container for LLVM modules. This one stores one
`llvm::Module` per function (all modules share the same
`llvm::LLVMContext` for performance reasons).
In the constructor of `InitRevng` also call all the `llvm::initialize*`
functions. This is done to be less implementation-specific and having
these functions be called in
`LLVMPipelineRegistry.libraryInitialization`.
`/` is now supported in names except for the parts of the model that use
the name as the key, i.e., `DynamicFunction` and `LocalIdentifier`.
Eventually, `/` should be allowed there as well, but we first need to
make sure that when they end up in a location they are properly
escaped/unescaped.
LLVM purges loads from `nullptr` in functions not marked with
`null_pointer_is_valid`. This can lead to uninitialized accesses to tiny
code variables, which in turn lead to cross-`TranslationBlock` phis
which can prevent argumentless outlining.
Adding to the `root` function the `null_pointer_is_valid` attribute
fixes this problem.
With this commit, the `simplifyTerminator` helper function used by IDS
stops trying to merge the default cases with one of the other cases
arbitrarily.
Now, if the `UnreachableSuccessor` was reached via the default case, the
default case is still arbitrarily redirected to an arbitrary case
successor, but the case and the default do not get merged.
This keeps the logic of the transform simpler, and also allows for
easier successive manipulation by planned upcoming transforms.
The implementation of `simplifyTerminator` is very specific to the
operations of IDS, can be easily misused, and is not currently used
anywhere else in the codebase.
This commit drops libptc in favor of its new form libtcg.
It brings several improvements, among which:
* The QEMU version we work on has been upgraded.
* CPUStateAccessAnalysis has been reimplemented in a way that makes it
easier to debug and solves some limitations (e.g., tracking leaking
pointers).
* Identification of pieces of the CPU state that are read by each helper
and fixing access to the CPU state is now performed at build-time.
* We no longer mmap the code we need to translate, dropping all the
issues related to code that needed to be mapped where something is
already present.
* We now have two distinct flavors of helper modules: the full one and
the "slim" one. The latter contains the definition only of functions
we intend to inline. It is used in most of the pipeline, a good thing
since we spend less time optimizing code we don't really care about.
The full module is only used on the re-compilation branch of the
pipeline.
* We no longer split the `cpu_loop` function.
* We change MetaAddress to rely on architectures from `model::` as
opposed to the LLVM ones.
* We no longer attach debug info to LLVM IR containing the original
assembly.
* We now verify that the lifted code only contains code we expect.
The current implementation DLA cannot reason about function pointers,
because function types have zero size.
Given this shortcoming, llvm::Functions are used (as a hack) to
represent their Functions' return types.
This representation is a key factor of how DLA is able to piece
information together interprocedurally.
This hack has consequences.
Assume we're setting up the DLA graph, and we're looking at a use of an
llvm::Function that is inside the body of an llvm::Function and is not
the callee-operand of a Call.
That use is obviously function-pointer typed.
But if we try to create a LayoutTypeSystemNode for the llvm::Value of
the used llvm::Function, the inner machinery of how the DLA graph is
set up will treat is as the return type of the function, which is
obviously wrong.
So we have to prevent that creation at all costs.
Basically creation of LayoutTypeSystemNodes in the DLA graph associated
with llvm::Functions are valid only for representing return types.
This shortcoming does not affect the power of DLA. In its current form,
it doesn't represent function types at all.
The problem is that until we undo this hack we will not be able to
properly support function types in DLA.
This will have to be fixed in the future.
In the meantime, this commit provides an helper function to centralize
how we detect the offending uses of llvm::Functions. In this way, all
the points of the codebase that are affected by this hack are clearly
marked.
Giacomo Vercesi