<div dir="ltr"><div>Hello LLVM developer community,</div><div><br></div><div>I'm a graduate student of the Technical University of Eindhoven with a potential</div><div>project for GSOC in mind that I would like to discuss.</div><div><br></div><div>The project is related to integrating support for the tool SWEET [1] into LLVM.</div><div>Please allow me to explain briefly what this SWEET tool is about and why I </div><div>think that integrating support for the tool is an interesting addition to LLVM.</div><div><br></div><div>SWEET is a tool developed by a research team at the Mälardalen University in </div><div>Västerås, Sweden. The tool allows one to compute the execution time of the </div><div>longest path of execution in a piece of code, this is called the Worst Case </div><div>Execution Time.  SWEET achieves this by using static analysis, meaning, that the </div><div>tool does not execute the code but looks at the code's structure and variables.</div><div><br></div><div>Computing the longest path of your code is really important in certain areas</div><div>of embedded systems, where the application code running on an embedded processor</div><div>has to meet a certain deadline. An example would be in aerospace, where the </div><div>longest path in cycles is typically computed by hand (!). Miss computing the </div><div>WCET could have disastrous results (e.g. an exploding rocket, car crash)</div><div><br></div><div>Now is were it gets interesting. SWEET has a novel approach to supporting new </div><div>targets via its interface language called ALF [2]. Typically, authors of </div><div>WCET static analysis tools have to implement support for specific target and </div><div>do not allow a third party to develop support for a new target. They also tend</div><div>to ask a large amount of money for supporting a new target. Did I mention </div><div>already that SWEET is open-source?</div><div><br></div><div>With this ALF interface language, all that is required to add a new target is</div><div>decompiling a given binary to ALF. Or: compiling it straight to ALF in the first</div><div>place. The GSOC project would be about making it easier to add for a certain </div><div>target a conversion to ALF. I suppose this would involve adding some sort of </div><div>abstraction in the code emission stage or in the MC layer. My knowledge of </div><div>the LLVM code base does not allow me to answer this question in full detail,</div><div>this is also one of the reasons why I am asking you for an opinion.</div><div><br></div><div>Note that going from IR to ALF is too high level and this leaves out important</div><div>details of the target. This can provide other advantages and has been attempted </div><div>before for the ALFBackend project [3]. The ALFBackend project already contains </div><div>some classes that models ALF and provides features for generating ALF code. So </div><div>there is a potential re-use.</div><div><br></div><div>I think I should also mention that I am in in contact with the research team</div><div>responsible for developing SWEET and with an aerospace software company that </div><div>is to write software for an embedded processor [4] that is to be used in the </div><div>Ariane-6 for the trust vector control. This could be a first use case, and a target</div><div>for proof of concept.</div><div><br></div><div>I would love to hear what you think.</div><div><br></div><div>Take care,</div><div><br></div><div>Rick Veens</div><div><br></div><div><br></div><div>[1] <a href="http://www.mrtc.mdh.se/projects/wcet/sweet/index.html">http://www.mrtc.mdh.se/projects/wcet/sweet/index.html</a></div><div>[2] <a href="http://www.mrtc.mdh.se/projects/all-times/documents/ALF/ALF-spec.pdf">http://www.mrtc.mdh.se/projects/all-times/documents/ALF/ALF-spec.pdf</a></div><div>[3] <a href="https://github.com/visq/ALF-llvm">https://github.com/visq/ALF-llvm</a></div><div>[4] <a href="http://clp-space.com/">http://clp-space.com/</a></div><div><br></div></div>