Add a python interface (`revng.profile`) for interacting with the rev.ng
infrastructure as a whole; either through the CLI (`CLIProject`) or the
GraphQL API (`DaemonProject`).
The logic of the `revng ptml` command was too tightly coupled with the
parsing of the xml. Overhaul the structure of the ptml code and split it
in two locations:
* `revng.ptml`: this module contains functions that allow easy
manipulation of PTML, both for printing it and for obtaining the split
metadata/text version.
* `revng.internal.cli._commands.ptml`: this implements the actual `revng
ptml` command. This leverages the new logic in the `revng.ptml` module
while maintaining the same functionality.
In this commit we instruct the build system to use the unified schema
files instead of collecting the `TUPLE-TREE-YAML` comments.
The fixes to C++ files are necessary because they depend on the order
of the fields in the schema, which was changed.
This pass wraps LLVM's vanilla InstCombine, to hijack one of its
options. The goal of this hijack is to prevent InstCombine from
splitting and replacing accesses to arrays with GEPs and smaller
accesses.
This pass wraps LLVM's vanilla SROA, to hijack one of its options.
The goal of this hijack is to prevent SROA from splitting and replacing
memory accesses to arrays with GEPs and smaller accesses.
This commit further centralizes the creation of allocas + ptrtoint. The
creation of these pair of instructions is problematic when the size of a
pointer in the input and target architecture differ.
In fact, in such cases, LLVM turns trunc into masking the integer to
suppresse the high bits. This results in problematic code.
This commit introduces an assumption that ensures LLVM does not do that.
The `prettier` binary is now assumed to be installed as part of the
system. No need to manually install it and use the `--prettier`
command-line option.
Passes without an artifact and a single successor are pointless anyway.
You can't get their output with revng artifact but you need to save
them on disk.
At the moment this pipe is broken, because it claims to be producing
artifacts with function rank, while it only produces types.
This pipe should be extended and turned into a pipe that generates
the whole Clift module including functions from LLVM IR, and not just
types.
We should add an input LLVMContainer, and the run() method should first
import types, and then create the functions and their bodies.
For the time being the Pipe is removed from the pipeline.
The previous conversion from LLVM to MLIR was translating plain LLVM IR
to LLVM MLIR Dialect, as a preliminary step for further conversion from
LLVM MLIR Dialect to Clift.
This is not how things are expected to work anymore, so the old code is
now dead and can be removed.
Introduce LegacySegregateStackAccessesPipe
This commit restructures the SegregateStackAccesses pass and
SegregateStackAccessesPipe so that they can have 2 modes of operations:
1. Legacy, with the same behavior as the old version, injecting local
variables as custom llvm::Functions representing opcodes, such as
LocalVariable, AddressOf, StackFrameAllocator, and CallStackArguments
allocator.
2. Non-legacy, that is meant to operate with the new LocalVariableHelper
to inject local variables as regular alloca instructions, with
additional metadata to discriminate among them.
This commit renames the old SegregateStackAccessesPipe to
LegacySegregateStackAccessesPipe.
It then re-uses the old SegregateStackAccessesPipe name for a new pipe,
meant to work in non-legacy mode.
The pipeline definition YAML file is updated to keep using the legacy
version for now.
For now the implementation is still the same.
The tests was testing if a function whose entry address is the target of
load was identified as a function or not (it shouldn't).
This test was passing accidentally. This has not been supported since
the introduction of `RootAnalyzer`. In order to support this again, we
need to resurrect `processLoadsAndStores`.
Giacomo Vercesi