Only the x86 softfloat helpers iterate over the vector-register lanes
with bounded `for` loops (e.g. the packed `helper_*p[sd]` operate on
`XMM/ZMM_D(i)`). `fix-helpers` can only rewrite the per-lane CSV
accesses once those loops are unrolled. This step is not needed on other
archs, so we avoid it to save space on the generated libtcg helpers and
build time.
Introduce a pass which statically demotes some helpers from candidates
for inlining:
1) Helpers which are part of SCC on the callgraph.
2) Helpers which contains an `insertvalue`.
3) Helpers which _fail_ the `CriticalArguments` criterion.
A critical argument is defined starting from the critical operand
definition.
A critical operand is either the condition of a `switch` instruction or
the indices of a `getelementptr` instruction.
If the dataflow computing the the operand trace back to a formal
parameter of the function, that parameter will be considered critical
when attempting the inlining of the helper.
In case each condition is satisfied, the `revng.inline.policy` metadata
is attached to the function, so that it can be used at _inline_ time to
take the decision based on the critical arguments constantness.
The metadata is encoded as an `iN` integer with N = `arg_size() + 1`:
the extra most-significant bit is always zero so LLVM's signed-decimal
`iN` printer renders the value positively (avoiding e.g. `!{i2 -2}`).
The (de)serialisation primitives live in `revng/Support/IRHelpers.h`
as `serializeInliningPolicy` / `deserializeInliningPolicy` so the
runtime `revngFunctionIsolation` doesn't need to link the build-time
`revngHelperInliningAnalyses` to read the metadata back.
Introduce a build-time pass that tags every QEMU helper transitively
reaching a function defined under one of the configured runtime-library
directories (currently `fpu/` only) as `revng_inline`. The intent is to
make the lift pipeline surface "leaf-level" runtime-library calls (e.g.
softfloat ops) directly in the lifted IR by inlining away every wrapper
helper that sits between QEMU's `helper_*` boundary and the leaf.
We also gate the tagging by a per-function body-size budget.
The pass is run in the pipeline building the `libtcg-helpers-full-*.bc`
artifacts.
Add the `revngHelperArgumentsAnalysis` library to the dependencies of
the helpers building pipeline, so they are rebuilt whenever there is a
change in the library.
This commit introduces an analysis to import prototypes from a SQLite
database of well-known prototypes, typically built from debug info of
operating systems.
This analysis supersedes import-well-known-models.
Re-organize the variants of `libtcg-helpers-*.bc` as such:
* `libtcg-helpers-full-$ARCH.bc`: unchanged, contains all helper
function with their bodies and all CSVs.
* `libtcg-helpers-declarations-only-$ARCH.bc`: all helper
functions have been turned to declarations. All CSVs (except a couple
of special ones) have been dropped.
* `libtcg-helpers-to-inline-$ARCH.bc`: only functions with the
`revng_inline` section retain their body. Only CSVs that are used by
these functions are present.
Lift now loads only the `declarations-only` variant of helpers, as
their body is not required until `inline-helpers`. In `inline-helpers`
the `to-inline` variant is loaded and linked, which then allows the
helpers to be inlined.
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.
This commit adds missing dependencies on autogenerated stuff to custom
commands using ./bin/revng
This is necessary because without those explicit dependencies, ninja
could decide to run commands involving ./bin/revng before the
autogenerated files were produced, resulting in errors when running
the ./bin/revng command that depends on them.
Drop using the `revng-` prefix from all executables under
`libexec/revng/`. Now any executable found under there that is
executable and without extension will be considered a `revng`
subcommand, following the usual command-line rules.
Generate the `share/revng/component-hashes/revng` file, which contains
the git commit from which the current build of revng (dirty files
notwithstanding) was built from.
Generate the `share/revng/component-hashes/revng-c` file, which
contains the git commit from which the current build of revng-c (dirty
files nonwithstanding) was built from.
Add a commented line in `CMakeLists.txt` to easily enable
`no-limit-debug-info`, which is useful to make debugging easier when
methods are missing from llvm classes.
Add a commented line in `CMakeLists.txt` to easily enable
`no-limit-debug-info`, which is useful to make debugging easier when
methods are missing from llvm classes.
Its presence lead to an undesirable situation where the file itself
would get copied to the install directory and using `add_subdirectory`
led to creating a set of support files (which would get installed too).
Simple solution: just push the content of that file in the root
`CMakeLists.txt`.
This analysis will be used for the following features:
1) Edit Type in the Model
2) Edit Function Prototype in the Model
3) Add Type to the Model
It takes C code as an input, parses it and produces a Model
type that represents the C type.
Andrea Gussoni