Because of a mistake with the last refactoring iteration, this extra
argument was lost when converting to RFTs (it was still present in
layouts). This commit reintroduces it.
Before this commit, the TypeSystemPrinter implicitly assumed that
model::Function and model::DynamicFunction always had a prototype.
However, this is not guaranteed by the model schema.
This commit extends the TypeSystemPrinter so that it doesn't make that
wrong assumption anymore, and can successfully print any model::Function
and model::DynamicFunction, even when a prototype is not present.
This commit drops calls to `_init_$CPU_STATE` for non-general purpose
registers. Instead, these part of the CPU state are initialized using
the initializer of the CSV, which is in turn provided by QEMU.
This enables us to properly initialize as appropriate fields such as
x86-64's DF flag.
After the changes to the direction `CrossRelation` output is parsed,
the slicer wasn't updated accordingly. Because of that, the slices were
as if they were produced backwards.
As for the full graph, since it starts from an artificially added node
that doesn't have any successors by definition - it was appearing empty
(only the non-emittable "root" node was present).
We now implement the `nodesBetween` primitive with a double DFS visit.
Specifically, we have:
1) A forward DFS that starts from the `Source`, and stops at `Target`.
2) A backward DFS that starts from the `Target`, and stops at `Source`.
The final result is then the intersection of the nodes found by the two
above DFS visits.
A new `findReachableNodes` primitive is also added to perform a DFS from
a `Source` node, which stops at the `Stop` parameter node, if present.
Added unit tests to improve the coverage.
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`.
The collection points of several ABI analyses where incorrect. Several
analyses that should have collected data only from entry points were
collecting data from any node in the graph.
Up until now, we did not need different !dbg/DISubprogram
attached to each isolated llvm::Function, but for the
purpose of MLIR lowering, we need it.
On the LLVM IR level, we used to reuse root's DISubpgram,
and we have not being attaching !dbg/DISubprogram to the
isolated functions at all (just to llvm::Instructions),
but that was an hack in order to avoid some LLVM verify
checks, since LLVM IR expects !dbg attachments to calls of
functions that could be inlined, but by avoid !dbg on the
Function itself, it won't verify !dbg attachments on the
instructions, since it will assume it has no debug info in
it. When it comes to MLIR, it expects different !dbg
attached to each function, in order to process debug info
in it, so that is the reason we cannot rely on the root
DISubprogram only anymore.
During this phase (EnforceABI) the binary is not meant to be run
so the debug info is not useful anymore, so we are striping them
now in order to avoid taking care of them during the pipeline.
Ivan Krysak