\chapter*{Wrapping it all up?}\label{chap:wrapping_up}

In \autoref{chap:palmed}, we introduced \palmed{}, a framework to build a
backend model. Following up in \autoref{chap:frontend}, we introduced a
frontend model for the ARM-based Cortex A72 processor. Then, in
\autoref{chap:staticdeps}, we further introduced a dependency detection model.

Put together, these three parts cover the major bottlenecks that a code
analyzer must take into account. It would thus be satisfying to conclude this
manuscript with a unified tool packing the three together, and evaluating the
full extent of this PhD against the state of the art.

\medskip{}

This is, sadly, not reasonably feasible without a good amount of engineering
effort and duct-tape code for multiple reasons.

\smallskip{}

First, the choice of the Cortex A72 as an architecture means relying on a
low-power processor and on the Raspberry Pi microcomputer for benchmarking
---~which has a low amount of RAM, a low-throughput storage and is prone to
overheating. This makes extensive benchmarking impractical.

There is also the heterogeneity of formats used to describe benchmarks. Some
tools, such as \staticdeps{}, rely on assembled objects and directly deal with
assembly. Some others use custom formats to describe assembly instructions and
their numerous declinations ---~for instance, the performance of \lstxasm{mov
\%rax, \%rbx} will be far from that of \lstxasm{mov 8(\%rax, \%r10), \%rbx},
despite being both a \texttt{mov} instruction. For one, \palmed{} uses such a
format, defined by \pipedream{} (its benchmarking backend), while \uopsinfo{}
uses a different one. Overall, this makes a challenge of using multiple tools
on the same code, and an even greater challenge of comparing the results
---~let alone pipelining them.

\bigskip{}

These models, however, should become really meaningful only when combined
together ---~or, even better, when each of them could be combined with any
other model of the other parts. To the best of our knowledge, however, no such
modular tool exists; nor is there any standardized approach to interact with
such models. The usual approach of the domain to try a new idea, instead, is to
create a full analyzer implementing this idea, such as what we did with \palmed{}
for backend models, or such as \uica{}'s implementation, focusing on frontend
analysis.

In hindsight, we advocate for the emergence of such a modular code analyzer.
It would maybe not be as convenient or well-integrated as ``production-ready''
code analyzers, such as \llvmmca{} ---~which is packaged for Debian. It could,
however, greatly simplify the academic process of trying a new idea on any of
the three main models, by decorrelating them. It would also ease the
comparative evaluation of those ideas, while eliminating many of the discrepancies
between experimental setups that make an actual comparison difficult ---~the
reason that prompted us to make \cesasme{} in \autoref{chap:CesASMe}. Indeed,
with such a modular tool, it would be easy to run the same experiment, in the
same conditions, while only changing \eg{} the frontend model but keeping a
well-tried backend model.