[llvm-dev] Potential Google Summer Of Code (GSOC) 2017 project

[Rick Veens via llvm-dev]

Hello LLVM developer community,

I'm a graduate student of the Technical University of Eindhoven with a
potential
project for GSOC in mind that I would like to discuss.

The project is related to integrating support for the tool SWEET [1] into
LLVM.
Please allow me to explain briefly what this SWEET tool is about and why I
think that integrating support for the tool is an interesting addition to
LLVM.

SWEET is a tool developed by a research team at the Mälardalen University
in
Västerås, Sweden. The tool allows one to compute the execution time of the
longest path of execution in a piece of code, this is called the Worst Case
Execution Time.  SWEET achieves this by using static analysis, meaning,
that the
tool does not execute the code but looks at the code's structure and
variables.

Computing the longest path of your code is really important in certain areas
of embedded systems, where the application code running on an embedded
processor
has to meet a certain deadline. An example would be in aerospace, where the
longest path in cycles is typically computed by hand (!). Miss computing
the
WCET could have disastrous results (e.g. an exploding rocket, car crash)

Now is were it gets interesting. SWEET has a novel approach to supporting
new
targets via its interface language called ALF [2]. Typically, authors of
WCET static analysis tools have to implement support for specific target
and
do not allow a third party to develop support for a new target. They also
tend
to ask a large amount of money for supporting a new target. Did I mention
already that SWEET is open-source?

With this ALF interface language, all that is required to add a new target
is
decompiling a given binary to ALF. Or: compiling it straight to ALF in the
first
place. The GSOC project would be about making it easier to add for a
certain
target a conversion to ALF. I suppose this would involve adding some sort
of
abstraction in the code emission stage or in the MC layer. My knowledge of
the LLVM code base does not allow me to answer this question in full detail,
this is also one of the reasons why I am asking you for an opinion.

Note that going from IR to ALF is too high level and this leaves out
important
details of the target. This can provide other advantages and has been
attempted
before for the ALFBackend project [3]. The ALFBackend project already
contains
some classes that models ALF and provides features for generating ALF code.
So
there is a potential re-use.

I think I should also mention that I am in in contact with the research team
responsible for developing SWEET and with an aerospace software company
that
is to write software for an embedded processor [4] that is to be used in
the
Ariane-6 for the trust vector control. This could be a first use case, and
a target
for proof of concept.

I would love to hear what you think.

Take care,

Rick Veens


[1] http://www.mrtc.mdh.se/projects/wcet/sweet/index.html
[2] http://www.mrtc.mdh.se/projects/all-times/documents/ALF/ALF-spec.pdf
[3] https://github.com/visq/ALF-llvm
[4] http://clp-space.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/8710ccbf/attachment.html>