| <!--#include virtual="../../header.incl" --> |
| |
| <div class="www_sectiontitle" id="top">2018 European LLVM Developers Meeting</div> |
| <div style="float:left; width:68%;"> |
| <div style="width:100%;"> |
| <ul> |
| <li><a href="index.html">Conference main page</a></li> |
| <li><b>Conference Dates</b>: April 16-17, 2018</li> |
| <li><b>Location</b>: |
| <a href="http://www.marriott.com/hotels/travel/brsdt-bristol-marriott-hotel-city-centre/"> |
| Bristol Marriott Hotel City Centre</a>, Bristol UK</li> |
| </ul> |
| </div> |
| |
| <div class="www_sectiontitle" id="about">About</div> |
| <p>The meeting serves as a forum for LLVM, Clang, LLDB and other LLVM project |
| developers and users to get acquainted, learn how LLVM is used, and exchange |
| ideas about LLVM and its (potential) applications. <p> |
| |
| <p>The conference includes:</p> |
| <ul> |
| <li><a href="#Keynotes">Keynotes</a></li> |
| <li><a href="#Tutorials">Tutorials</a></li> |
| <li><a href="#Talks">Technical talks</a></li> |
| <li><a href="#Lightning_Talks">Lightning talks</a></li> |
| <li><a href="#BoFs">BoFs</a></li> |
| <li><a href="#Posters">Poster session</a></li> |
| <li>hacker’s lab</li> |
| <li>and a reception. </li> |
| </ul> |
| |
| |
| <div class="www_sectiontitle" id="Keynotes">Keynotes</div> |
| |
| <table cellpadding="10"><tr><td valign="top" id="Keynote_1"> |
| <b>The Cerberus Memory Object Semantics for ISO and De Facto C</b><br> |
| <i>P. Sewell</i> |
| <p>The semantics of pointers and memory objects in C has been a vexed question |
| for many years. C values cannot be treated as simple abstract or concrete |
| entities: the language exposes their representations, but compiler |
| optimisations rely on analyses that reason about provenance and initialisation |
| status, not just runtime representations. The ISO standard leaves much of this |
| unclear, and in some aspects differs with de facto standard usage - which |
| itself is difficult to investigate.</p> |
| <p>This talk will describe our candidate source-language semantics for memory |
| objects and pointers in C, as it is used and implemented in practice. |
| Focussing on provenance and uninitialised values, we propose a coherent set of |
| choices for a host of design questions, based on discussion with the ISO WG14 C |
| standards committee and previous surveys of C experts. This should also inform |
| design of the LLVM internal language semantics, and it seems that our |
| source-language proposal and the LLVM proposal by Lopes, Hur, et al. can be |
| made compatible.</p> |
| <p>Our semantics is integrated with the Cerberus semantics for much of the rest |
| of C, with a clean translation of C into a Core intermediate language. |
| Together, the two make C undefined behaviours explicit. Cerberus has a |
| web-interface GUI in which one can explore all the allowed behaviours of small |
| test programs, and which also identifies the clauses of the C standard relevant |
| to typechecking and translating each test. Work-in-progress URL: |
| <a href="http://svr-pes20-cerberus.cl.cam.ac.uk/">http://svr-pes20-cerberus.cl.cam.ac.uk/</a></p> |
| <p>We also describe detailed proposals to WG14, showing how the semantics can |
| be incorporated into the ISO standard.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Keynote_2"> |
| <b>LLVM x Blockchains = A new Ecosystem of Decentralized Applications</b><br> |
| <i>R. Zhong</i> |
| <p>Recently, blockchains are showing more and more power as application |
| platforms besides transaction-trading platforms. Running applications on |
| decentralized platforms totally differs from the way we did before. And we can |
| foresee, developers will redefine existing centralized applications and create |
| different decentralized applications. However, the foundations are not ready |
| yet. Both academia and industry are exploring how to enpower the decentralized |
| applications. We, Nebulas, call on the LLVM community to bring LLVM to the |
| blockchain community.</p> |
| <p>We propose several open problems needing to be addressed with the target of |
| leveraging LLVM in blockchains. Besides, we also share our work on using LLVM |
| to build a smart contract execution engine.</p> |
| </td></tr></table> |
| |
| <div class="www_sectiontitle" id="Tutorials">Tutorials</div> |
| |
| <table cellpadding="10"><tr><td valign="top" id="Tutorial_1"> |
| <b>Pointers, Alias & ModRef Analyses </b><br> |
| <i>A. Sbirlea, N. Lopes</i> |
| <p>Alias analysis is widely used in many LLVM transformations. In this |
| tutorial, we will give an overview of pointers, Alias and ModRef analyses. We |
| will first present the concepts around pointers and memory models, including |
| the representation of the different types of pointers in LLVM IR, then discuss |
| the semantics of ptrtoint, inttoptr and getelementptr and how they, along with |
| pointer comparison, are used to determine memory overlaps. We will then show |
| how to efficiently and correctly use LLVM’s alias analysis infrastructure, |
| introduce the new API changes, as well as the highlight common pitfalls in the |
| usage of these APIs.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Tutorial_2"> |
| <b>Scalar Evolution - Demystified</b><br> |
| <i>J. Absar</i> |
| <p>This is a tutorial/technical-talk proposal for an illustrative and in-depth |
| exposition of Scalar Evolution in LLVM. Scalar Evolution is an LLVM analysis |
| that is used to analyse, categorize and simplify expressions in loops. Many |
| optimizations such as - generalized loop-strength-reduction, parallelisation by |
| induction variable (vectorization), and loop-invariant expression elimination - |
| rely on SCEV analysis.</p> |
| <p>However, SCEV is also a complex topic. This tutorial delves into how exactly |
| LLVM performs the SCEV magic and how it can be used effectively to implement |
| and analyse different optimisations.</p> |
| |
| <p>This tutorial will cover the following topics: |
| <ol> |
| <li>What is SCEV? How does it help improve performance? SCEV in action (using |
| simple clear examples).</li> |
| <li>hain of Recurrences - which forms the mathematical basis of SCEV.</li> |
| <li>Simplifying/rewriting rules in CR that SCEV uses to simplify expressions |
| evolving out of induction variables. Terminology and SCEV Expression Types |
| (e.g. AddRec) that is common currency that one should get familiar with when |
| trying to understand and use SCEV in any context.</li> |
| <li>LLVM SCEV implementation of CR - what's present and what's missing?</li> |
| <li>How to use SCEV analysis to write your own optimisation pass? Usage of |
| SCEV by LSR (Loop Strength Reduce) and others.</li> |
| <li>How to generate analysis info out of SCEV and how to interpret them.</li> |
| </ol> |
| |
| <p>The last talk on SCEV was in LLVM-Dev 2009. This tutorial will be |
| complementary to that and go further with examples, discussions and evolution |
| of scalar-evolution in llvm since then. The author has previously given a talk |
| on machine scheduler in llvm - |
| <a href="https://www.youtube.com/watch?v=brpomKUynEA&t=310s">https://www.youtube.com/watch?v=brpomKUynEA&t=310s</a></p> |
| </td></tr></table> |
| |
| <div class="www_sectiontitle" id="BoFs">BoFs (Birds of a Feather)</div> |
| <p style='text-align: right'>[<a href="#top">top</a>]</p> |
| |
| <table cellpadding="10"><tr><td valign="top" id="BoF_1"> |
| <b>Towards implementing #pragma STDC FENV_ACCESS </b><br> |
| <i>U. Weigand</i> |
| <p>When generating floating-point code, clang and LLVM will currently assume |
| that the program always operates under default floating-point control modes, |
| i.e. using the default rounding mode and with floating-point exceptions |
| disabled, and never checks the floating-point status flags. This means that |
| code that does attempt to make use of these IEEE features will not work |
| reliably. The C standard defines a pragma FENV_ACCESS that is intended to |
| instruct the compiler to switch to a method of generating code that will allow |
| these features to be used, but this pragma and the associated infrastructure is |
| not yet implemented in clang and LLVM.</p> |
| <p>The purpose of this BoF is to bring together all parties interested in this |
| feature, whether as potential users, or as experts in any of the parts of the |
| compiler that will need to be modified to implement it, from the clang front |
| end, through the optimizers, to the various back ends that need to emit |
| appropriate code for their platform. We will discuss the current status of the |
| partial infrastructure that is already present, identify the pieces that are |
| still missing, and hopefully agree on next steps to move towards a full |
| implementation of pragma FENV_ACCESS in clang and LLVM.</p> |
| <hr> |
| </td></tr> |
| <tr><td valign="top" id="BoF_2"> |
| <b>Build system integration for interactive tools </b><br> |
| <i>I. Biryukov, H. Wu, E. Liu, S. McCall</i> |
| <p>The current approach for integrating clang tools with build systems |
| (CompilationDatabase, compile_commands.json) was designed for running command |
| line tools and it lacks some important features that would be nice to have for |
| interactive tools like clangd, e.g. tracking updates to the compilation |
| commands for existing files or propagating information like file renames back |
| to the build system. The current approach also requires interference from the |
| users of the tools to generate compile_commands.json even for the build systems |
| that support it. On the other hand, there are existing tools like CLion and |
| Visual Studio that integrate seamlessly with their supported build systems and |
| “just work” for the users without extra configuration. Arguably, this approach |
| provides a better user experience. It would be interesting to explore existing |
| build systems and approaches for integrating them with interactive clang-based |
| tools and improving user experience in that area. </p> |
| <hr> |
| </td></tr> |
| <tr><td valign="top" id="BoF_3"> |
| <b>Clang Static Analyzer BoF</b><br> |
| <i>Devin Coughlin</i> |
| <p>BoF for the users and implementors of the Clang Static Analyzer. Suggested |
| agenda: 1. Quick presentation of the ongoing development activities in the |
| Static Analyzer community 2. Discussion of the main annoyances using the Static |
| Analyzer (e.g. sources of false positives) 3. Discussion of the most wanted |
| checks for the Static Analyzer 4. Discussion of missing capabilities of the |
| Analyzer (statistical checks, pointer analysis, ...) 5. Discussion of the |
| constraint solver limitations and proposed solutions 6. Discussion of future |
| directions</p> |
| <hr> |
| </td></tr> |
| <tr><td valign="top" id="BoF_4"> |
| <b>LLVM Foundation BoF</b><br> |
| <i>LLVM Foundation Board of Directors</i> |
| </td></tr> |
| </table> |
| |
| <div class="www_sectiontitle" id="Talks">Technical Talks</div> |
| <p style='text-align: right'>[<a href="#top">top</a>]</p> |
| |
| <table cellpadding="10"><tr><td valign="top" id="Talk_1"> |
| <b>A Parallel IR in Real Life: Optimizing OpenMP</b><br> |
| <i>H. Finkel, J. Doerfert, X. Tian, G. Stelle </i> |
| <p>Exploiting parallelism is a key challenge in programming modern systems |
| across a wide range of application domains and platforms. From the world's |
| largest supercomputers, to embedded DSPs, OpenMP provides a programming model |
| for parallel programming that a compiler can understand and optimize. While |
| LLVM's optimizer has not traditionally been involved in OpenMP's |
| implementation, with all of the outlining logic and translation into |
| runtime-library calls residing in Clang, several groups have been experimenting |
| with implementation techniques that push some of this translation process into |
| LLVM itself. This allows the optimizer to simplify these parallel constructs |
| before they're transformed into runtime calls and outlined functions.</p> |
| <p>We've experimented with several techniques for implementing a parallel IR in |
| LLVM, including adding intrinsics to represent OpenMP constructs (as proposed |
| by Intel and others) and using Tapir (an experimental extension to LLVM |
| originally developed at MIT), and have used these to lower both parallel loops |
| and tasks. Nearly all parallel IR techniques allow for analysis information to |
| flow into the parallel code from the surrounding serial code, thus enabling |
| further optimization, and on top of that, we've implemented optimizations such |
| as fusion of parallel regions and the removal of redundant barriers. In this |
| talk, we'll report on these results and other aspects of our experiences |
| working with parallel extensions to LLVM's IR.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_2"> |
| <b>An Introduction to AMD Optimizing C/C++ Compiler </b><br> |
| <i>A. Team</i> |
| <p>In this paper we introduce some of the optimizations that are a part of AMD |
| C/C++ Optimizing Compiler 1.0 (AOCC 1.0) which was released in May 2017 and is |
| based on LLVM Compiler release 4.0.0. AOCC is AMD’s CPU performance compiler |
| which is aimed at optimizing the performance of programs running on AMD |
| processors. In particular, AOCC 1.0 is tuned to deliver high performance on |
| AMD’s EPYC(TM) server processors. The performance results for |
| SPECrate®2017_int_base, SPECrate®2017_int_peak [1], SPECrate®2017_fp_base and |
| SPECrate®2017_fp_peak [2] that we include in the paper show that AOCC delivers |
| excellent performance thereby enhancing the power of the AMD EPYC(TM) |
| processor. The optimizations fall into the categories of loop vectorization, |
| SLP vectorization, data layout optimizations and loop optimizations. We shall |
| introduce and provide some details of each optimization.</p> |
| [1] <a href="https://www.spec.org/cpu2017/results/res2017q4/cpu2017-20171031-00334.html">https://www.spec.org/cpu2017/results/res2017q4/cpu2017-20171031-00334.html</a><br> |
| [2] <a href="https://www.spec.org/cpu2017/results/res2017q4/cpu2017-20171031-00366.html">https://www.spec.org/cpu2017/results/res2017q4/cpu2017-20171031-00366.html</a> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_3"> |
| <b>Analysis of Executable Size Reduction by LLVM passes </b><br> |
| <i>V. Sinha, P. Kumar, S. Jain, U. Bora, S. Purini, R. Upadrasta </i> |
| <p>Increase in the number of embedded devices and the demand to run resource |
| intensive programs on these limited memory systems has necessitated the |
| reduction of executable size of programs. LLVM offers an out-of-box -Oz |
| optimization that is specifically targeted for the reduction of generated |
| executable size. However, the formidable increase in the interest of making |
| smaller and smarter devices has compelled programmers to develop more |
| complicated programs for embedded systems.</p> |
| <p>In this work, we aim to cater to the specific need of compiler driven |
| reduction of executable size for such memory critical devices. We go beyond the |
| traditional series of passes executed by -Oz; we try to break this series into |
| logical groups and study their effect, as well as the effect of their |
| combinations, on size of the executable.</p> |
| <p>Our preliminary study over SPEC 2017 benchmarks gives an insight into the |
| comparative effect of the groups of passes on executable size. Our work has |
| potential to enable the developer to tailor a custom series of passes so as to |
| obtain the desired executable size. To further aid such a customization, we |
| create a prediction model (based on simple linear regression) that is correctly |
| able to predict the executable size obtained by a combination of groups when |
| given only the sizes obtained by the individual groups.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_4"> |
| <b>Developing Kotlin/Native infrastructure with LLVM/Clang, travel notes. </b><br> |
| <i>N. Igotti </i> |
| <p>In September of 2016 JetBrains started development of LLVM-based Kotlin |
| compiler and runtime. Since then, we have reached version 0.5, which compiles |
| to most LLVM targets (Linux, Windows and macOS as OS; x86, ARM and MIPS as CPU |
| architectures, along with more exotic WebAssembly) and supports smooth interop |
| with arbitrary C and Objective-C libraries. This talk will give some highlights |
| on challenges we faced during development of this backend, with emphasis on |
| LLVM-related topics.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_5"> |
| <b>Extending LoopVectorize to Support Outer Loop Vectorization Using VPlan </b><br> |
| <i>D. Caballero, S. Guggilla </i> |
| <p>The introduction of the VPlan model in Loop Vectorizer (LV) started as a |
| refactoring effort to overcome LV’s existing limitations and extend its |
| vectorization capabilities to outer loops. So far, progress has been made on |
| the refactoring part by introducing the VPlan model to record the vectorization |
| and unrolling decisions for candidate loops and generate code out of them. This |
| talk focuses on the strategy to bring outer loop vectorization capabilities to |
| Loop Vectorizer by introducing an alternative vectorization path in LV that |
| builds VPlan upfront in the Loop Vectorizer pipeline. We discuss how this |
| approach, in the short term, will add support for vectorizing a subset of |
| simple outer loops annotated with vectorization directives (#pragma omp simd |
| and #pragma clang loop vectorize). We also talk about the plan to extend the |
| support towards generic outer and inner loop auto-vectorization through the |
| convergence of both vectorization paths, the new alternative vectorization path |
| and the existing inner loop vectorizer path, into a single one with advanced |
| VPlan-based vectorization capabilities.</p> |
| <p>We conclude the talk by describing potential opportunities for the LLVM |
| community to collaborate in the development of this effort.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_6"> |
| <b>Finding Iterator-related Errors with Clang Static Analyzer </b><br> |
| <i>Á. Balogh </i> |
| <p>The Clang Static Analyzer is a sub-project of Clang that performs source |
| code analysis on C, C++, and Objective-C programs. It is able to find deep bugs |
| by symbolically executing the code. However, this far finding C++ iterator |
| related bugs was a white spot in the analysis. In this work we present a set of |
| checkers that detects three different bugs of this kind: out-of-range iterator |
| dereference, mismatch between iterator and container or two iterators and |
| access of invalidated iterators. Our combined checker solution is capable |
| finding all these errors even in in less straightforward cases. It is generic |
| so it do not only work on STL containers, but also on iterators of custom |
| container types. During the development of the checker we also had to overcome |
| some infrastructure limitations from which also other (existing and future) |
| checkers can benefit. The checker is already deployed inside Ericsson and is |
| under review by the community.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_7"> |
| <b>Finding Missed Optimizations in LLVM (and other compilers) </b><br> |
| <i>G. Barany</i> |
| <p>Randomized differential testing of compilers has had great success in |
| finding compiler crashes and silent miscompilations. In this talk I explain how |
| I used the same approach to find missed optimizations in LLVM and other open |
| source compilers (GCC and CompCert).</p> |
| <p>I compile C code generated by standard random program generators and use a |
| custom binary analysis tool to compare the output programs. Depending on the |
| optimization of interest, the tool can be configured to compare features such |
| as the number of total instructions, multiply or divide instructions, function |
| calls, stack accesses, and more. A standard test case reduction tool produces |
| minimal examples once an interesting difference has been found.</p> |
| <p>I have used these tools to compare the code generated by GCC, Clang, and |
| CompCert. I found previously unreported missing arithmetic optimizations in all |
| three compilers, as well as individual cases of unnecessary register spilling, |
| missed opportunities for register coalescing, dead stores, redundant |
| computations, and missing instruction selection patterns. In this talk I will |
| show examples of optimizations missed by LLVM in particular, both |
| target-independent mid-end issues and ones in the ARM back-end.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_8"> |
| <b>Global code completion and architecture of clangd </b><br> |
| <i>E. Liu, H. Wu, I. Biryukov, S. McCall </i> |
| <p>Clangd is an implementation of the Language Server Protocol (LSP) server |
| based on clang’s frontend and developed as part of LLVM in the |
| clang-tools-extra repository. LSP is the relatively new initiative to |
| standardize the protocol for providing intelligent semantic code editing |
| features independent of a particular text editor. Clangd aims to support very |
| large codebases and provide intelligent IDE features like code completion on a |
| project-wide scale. In this talk, we’ll cover the architecture of clangd and |
| talk in-depth about the feature we’ve been working on in the last few months: |
| the global code completion.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_9"> |
| <b>Hardening the Standard Library</b><br> |
| <i>M. Clow</i> |
| <p>Every C++ program depends on a standard library implementation. For LLVM |
| users, this means that libc++ is at the bottom of their dependency graph. It is |
| vital that this library be correct and performant.</p> |
| <p>In this talk, I will discuss some of the principles and tools that we use to |
| make libc++ as "solid" as possible. I'll talk about preconditions, |
| postconditions, reading specifications, finding problems, ensuring that bugs |
| stay fixed, as well as several tools that we use to achieve our goal of making |
| libc++ as robust as possible.</p> |
| <p>Some of the topics I'll discuss are: </p> |
| <ul> |
| <li> Precondition checking - when practical.</li> |
| <li> Warning eradication </li> |
| <li> The importance of a comprehensive test suite for both correctness and |
| ensuring that bugs don't reappear.</li> |
| <li> Static analysis</li> |
| <li> Dynamic analysis </li> |
| <li> Fuzzing</li> |
| </ul> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_10"> |
| <b>Implementing an LLVM based Dynamic Binary Instrumentation framework </b><br> |
| <i>C. Hubain, C. Tessier</i> |
| <p>This talk will go over our efforts to implement a new open-source DBI |
| framework based on LLVM.</p> |
| <p>We have been using DBI frameworks in our work for a few years now: to gather |
| coverage information for fuzzing, to break whitebox cryptography |
| implementations used in DRM or to simply assist reverse engineering.</p> |
| <p>However we were dissatisfied with the state of existing DBI frameworks: they |
| were either not supporting mobile architectures, too focused on a very specific |
| use cases or very hard to use. This prompted the idea of developing QBDI |
| (<a href="https://qbdi.quarkslab.com">https://qbdi.quarkslab.com</a>), |
| a new framework which has been in development for two years and a half.</p> |
| <p>With QBDI we wanted to try a modern take on DBI framework design and build a |
| tool crafted to support mobile architectures from the start, adopting a modular |
| design enabling its integration with other tools and that was easy to use by |
| abstracting all the low-level details from the users.</p> |
| <p>During the talk, we will review the motivation behind the usage of a DBI. We |
| will explain its core principle and the main implementation challenges we |
| faced. We will share some lessons learned in the process and how it changed the |
| way we think about dynamic instrumentation tools.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_11"> |
| <b>LLVM Greedy Register Allocator – Improving Region Split Decisions</b><br> |
| <i>M. Yatsina</i> |
| <p>LLVM Code Generation provides several alternative passes for performing |
| register allocation. Most of the LLVM in-tree targets use the Greedy Register |
| Allocator, which was introduced in 2011. An overview of this allocator was |
| presented by Jakob Olesen at the LLVM Developers' Meeting of that year (*). |
| This allocator relies on splitting live ranges of variables in order to cope |
| with excessive co-existing registers. In this technique a live range is split |
| into two or more smaller subranges, where each subrange can be assigned a |
| different register or be spilled.</p> |
| <p>This talk revisits the Greedy Register Allocator available in current LLVM, |
| focusing on its live range region splitting mechanism. We show how this |
| mechanism chooses to split live ranges, examine a couple of cases exposing |
| suboptimal split decisions, and present recent contributions along with their |
| performance impact.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_12"> |
| <b>MIR-Canon: Improving Code Diff Through Canonical Transformation. </b><br> |
| <i>P. Lotfi</i> |
| <p>Comparing IR and assembly through diff-tools is common but can involve |
| tediously reasoning through differences that are semantically equivalent. The |
| development of GlobalISel presented problems of correctness verification |
| between two programs compiled from identical IR using two different instruction |
| selectors (SelectionDAG versus GlobalISel) where outcomes of each selector |
| should ideally be reducible to identical programs. It is in this context that |
| transforming the post-ISel Machine IR (MIR) to a more canonical form shows |
| promise.</p> |
| <p>To address said verification challenges we have developed a MIR |
| Canonicalization pass in the LLVM open source tree to perform a host of |
| transformations that help to reduce non-semantic differences in MIR. These |
| techniques include canonical virtual register renaming (based on the order |
| operands are walked in the def-use graph), canonical code motion of defs in |
| relation to their uses, and hoisting of idempotent instructions.</p> |
| <p>In this talk we will discuss these algorithms and demonstrate the benefits |
| of using the tool to canonicalize code prior to diffing MIR. The tool is |
| available for the whole LLVM community to try.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_13"> |
| <b>New PM: taming a custom pipeline of Falcon JIT </b><br> |
| <i>F. Sergeev</i> |
| <p>Over the few last months we at Azul were teaching Falcon, our LLVM based |
| optimizing JIT compiler, to leverage the new pass manager framework. This talk |
| will focus on our motivation as well as practical experience in getting an |
| extensive custom LLVM pipeline to production under the new pass manager.</p> |
| <p>I will cover the current state of LLVM pass manager as viewed from our |
| "downstream" side, issues we met while converting, as well as our expectations |
| and how well they were met at the end.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_14"> |
| <b>Organising benchmarking LLVM-based compiler: Arm experience </b><br> |
| <i>E. Astigeevich</i> |
| <p>The ARM Compiler 6 is a product based on Clang/LLVM projects. Basing your |
| product on Clang/LLVM sources brings challenges in organizing the product |
| development lifecycle. You need to decide how to synchronize downstream and |
| upstream repositories. The decision impacts ways of testing and benchmarking. |
| The Arm compiler team does development of the compiler on the upstream trunk |
| keeping a downstream repository synchronized with the upstream trunk. Upstream |
| public build bots guard us from commits which can break our builds. We also |
| have infrastructure to do additional testing. There are a few public |
| performance tracking bots which run the LLVM test-suite benchmarks. Although |
| the LLVM test-suite covers many use cases, products often have to care about a |
| wider variety of use cases. So you will have to track quality of code |
| generation on other programs too. In this presentation we will explain how we |
| protect the Arm compiler product from code generation quality issues that the |
| public bots don’t catch. We will cover topics like continuous regression |
| tracking, process of fixing regressions, a benchmarking infrastructure. We will |
| show that the most important part of protecting the quality of a LLVM-based |
| product is to be closely involved into development of the upstream LLVM which |
| means detect issues in the upstream LLVM as early as possible and report them |
| as soon as possible. We hope our experience will enable both better |
| LLVM-derived products to be made and for product teams of other companies to |
| contribute to LLVM itself more effectively.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_15"> |
| <b>Performance Analysis of Clang on DOE Proxy Apps</b><br> |
| <i>H. Finkel, B. Homerding</i> |
| <p>The US Department of Energy has released nearly 50 proxy applications (<a |
| href="http://proxyapps.exascaleproject.org/">http://proxyapps.exascaleproject.org/</a>). |
| These are simplified applications that represent key characteristics of a wide |
| class of scientific computing workloads. We've conducted in-depth performance |
| analysis of Clang-generated code for these proxy applications, comparing to |
| GCC-compiled code and, in some cases, code generated by vendor compilers, and |
| have found some interesting places where Clang could do better. In this talk, |
| we'll walk through several interesting examples and present some data on |
| overall trends which, in some cases, are surprising.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_16"> |
| <b>Point-Free Templates </b><br> |
| <i>A. Gozillon, P. Keir</i> |
| <p>Template metaprogramming is similar to many functional languages; it's pure |
| with immutable variables. This encourages a similar programming style; which |
| begs the question: what functional features can be leveraged to make template |
| metaprogramming more powerful? Currying is just such a technique, with |
| increasing use cases. For example the ability to make concise point-free |
| metafunctions using partially applied combinators and higher-order functions. |
| Such point-free template metafunctions can be leveraged as a stand-in for the |
| lack of type-level lambda abstractions in C++. Currently there exist tools for |
| converting pointful functions to point-free functions in certain functional |
| languages. These can be used for quickly creating point-free variations of a |
| metafunction or finding reusable patterns. As part of our research we have made |
| a point-free template conversion tool using Clang LibTooling that takes |
| pointful metafunctions and converts them to point-free metafunctions that can |
| be used in lieu of type-level lambdas.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Talk_17"> |
| <b>Protecting the code: Control Flow Enforcement Technology </b><br> |
| <i>O. Simhon</i> |
| <p>Return-Oriented Programming (ROP), and similarly Call/Jump-Oriented |
| Programming (COP/JOP), have been the prevalent attack methodology for stealth |
| exploit writers targeting vulnerabilities in programs. Intel introduces |
| Control-flow Enforcement Technology (CET) [1] which is a HW-based solution for |
| protecting from gadget-based ROP/COP/JOP attacks. The new architecture deals |
| with such attacks using Indirect Branch Tracking and Shadow Stack. The required |
| support is implemented in LLVM and includes optimized lightweight |
| instrumentation. This talk targets LLVM developers who are interested in new |
| security architecture and methodology implemented in LLVM. Attendees will get |
| familiar with basic control flow attacks, CET architecture and its LLVM |
| compiler aspects. <br> |
| [1] <a href="https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf">https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf</a></p> |
| </td></tr></table> |
| |
| <div class="www_sectiontitle" id="Lightning_Talks">Lightning talks</div> |
| <p style='text-align: right'>[<a href="#top">top</a>]</p> |
| |
| <table cellpadding="10"><tr><td valign="top" id="Lightning_1"> |
| <b>C++ Parallel Standard Template LIbrary support in LLVM </b><br> |
| <i>M. Dvorskiy, J. Cownie, A. Kukanov</i> |
| <p>The C++17 standard has introduced extensions to the Standard Template |
| Library (STL) to allow the expression of parallelism through the Parallel STL. |
| In this talk we describe the extensions, how to use them, and how we are |
| intending to support them in Clang/LLVM.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_2"> |
| <b>Can reviews become less of a bottleneck?</b><br> |
| <i>K. Beyls</i> |
| <p>Many contributors to LLVM have experienced that sometimes the hardest part |
| of making a contribution is to get reviews for changes you propose. To put it |
| another way, one of the main limiting factors of the speed at which the LLVM |
| project improves is review bandwidth. In an attempt to gain some insights on |
| this and go beyond anecdotal evidence, I analysed the patterns of code review |
| interactions over the past 3 years, as they happened on reviews.llvm.org.</p> |
| <p>A few examples of statistics and insights I'll share are: - A small number |
| of people do the bulk of the code reviews. The distribution of reviews done per |
| reviewer seems to follow a power law. - On average, every patch for which you |
| request review needs 2.5 review comments from someone outside your direct team |
| before it can be committed. - One consequence of the above data is that for |
| every review you request, you should aim to do at least 2.5 useful review |
| comments for people outside your direct team, to pay your fair share in |
| reviews.</p> |
| <p>Many developers want to pay back their "review debt". However, with over 200 |
| changes to open reviews every day, it is difficult and time consuming to find a |
| review that you can help with. I will share a few ideas and experiments on how |
| to make it easier to find the open reviews that you can help with.</p> |
| <p>Overall, I hope this lightning talk can help towards making review slightly |
| less of a bottleneck for the LLVM project.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_3"> |
| <b>Clacc: OpenACC Support for Clang and LLVM </b><br> |
| <i>J. Denny, S. Lee, J. Vetter </i> |
| <p>We are working on a new project, clacc, to contribute production-quality |
| OpenACC compiler support to upstream clang and LLVM. A key feature of the clacc |
| design is to translate OpenACC to OpenMP in order to build on clang’s existing |
| OpenMP compiler and runtime support. The purpose of this talk is to describe |
| the clacc goals, design decisions, and challenges that we have encountered so |
| far in our prototyping efforts. We have begun preliminary design discussions on |
| the clang developers mailing list and plan to continue these discussions |
| throughout the development process to ensure the final clacc design is |
| acceptable by the community.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_4"> |
| <b>DragonFFI: Foreign Function Interface and JIT using Clang/LLVM </b><br> |
| <i>A. Guinet</i> |
| <p>DragonFFI is a Clang/LLVM-based library that allows calling C functions and |
| using C structures from any languages. It will show how Clang and LLVM are used |
| to make this happen, and the pros/cons against similar libraries (like |
| (c)ffi).</p> |
| <p>In 2014, Jordan Rose and John McCall from Apple presented a talk about using |
| Clang to call C functions from foreign languages. They showed issues they had |
| doing it, especially about dealing with various ABI.</p> |
| <p>DragonFFI provides a way to easily call C functions and manipulate C |
| structures from any language. Its purpose is to parse C libraries headers |
| without any modifications and transparently use them in a foreign language, |
| like Python or Ruby. In order to deal with ABI issues previously demonstrated, |
| it uses Clang to generate scalar-only wrappers of C functions. It also uses |
| generated debug metadata to have introspection on structures.</p> |
| <p>This talk will present the tool, how Clang and LLVM are used to provide |
| these functionalities, and the pros and cons against what other similar |
| libraries like (c)ffi [0] [1] are doing. It will show the actual limitations of |
| Clang we had to circumvent, and the overall internal working of DragonFFI.</p> |
| <p>In an effort to try and get help from the community, we will also present a |
| list of tasks of various difficulties that can be done to participle in the |
| project.</p> |
| <p>This library is in active development and is still in an alpha/beta |
| stage.</p> |
| <p>Source code of the whole project is available here: <a |
| href="https://github.com/aguinet/dragonffi">https://github.com/aguinet/dragonffi</a>. |
| Python packages can be installed using pip under Linux 32/64 bits and OSX 32/64 |
| bits (pip install pydffi).</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_5"> |
| <b>Easy::Jit: Compiler-assisted library to enable Just-In-Time compilation for C++ codes </b><br> |
| <i>J. Fernandez, S. Guelton</i> |
| <p>Compiled languages like C++ generally don't have access to Just-in-Time |
| facilities, which limits the range of possible optimizations. We introduce a |
| framework to enable dynamic recompilation of some functions, using runtime |
| information to improve the compiled code. This framework gives the user a clean |
| abstraction and does not need to rely on specific compiler knowledge.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_7"> |
| <b>Flang -- Project Update</b><br> |
| <i>S. Scalpone</i> |
| <p>Lightning talk with current status of Flang, a Fortran front-end for LLVM. |
| Cover current status of community, software, and short-term roadmap.</p> |
| <b>Look-Ahead SLP: Auto-vectorization in the Presence of Commutative Operations </b><br> |
| <i>V. Porpodas, R. Rocha, L. Góes</i> |
| <p>Auto-vectorizing compilers automatically generate vector (SIMD) instructions |
| out of scalar code. The state-of-the-art algorithm for straight-line code |
| vectorization is Superword-Level Parallelism (SLP). In this work, we identify a |
| major limitation at the core of the SLP algorithm, in the performance-critical |
| step of collecting the vectorization candidate instructions that form the |
| SLP-graph data structure. SLP lacks global knowledge when building its |
| vectorization graph, which negatively affects its local decisions when it |
| encounters commutative instructions. We propose LSLP, an improved algorithm |
| that can plug-in to existing SLP implementations, and can effectively vectorize |
| code with arbitrarily long chains of commutative operations. LSLP relies on |
| short-depth look-ahead for better-informed local decisions. Our evaluation on a |
| real machine shows that LSLP can significantly improve the performance of |
| real-world code with little compilation-time overhead.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_10"> |
| <b>Low Cost Commercial Deployment of LLVM</b><br> |
| <i>J. Bennett</i></i> |
| <p>Deployment of a full new port of LLVM for general commercial use typically |
| requires several engineer years of effort. With a large and diverse community |
| of users, there are demanding requirements for features, reliability and |
| performance if the compiler is to be successful.</p> |
| <p>This cost is perfectly reasonable in supporting a major processor design, |
| whose development will have been an order of magnitude more expensive. However |
| there are many other processors which do not fall into this category, |
| particularly custom DSPs and other specialist processors. Such devices are |
| often only used by the company which designed them and are typically programmed |
| in assembly language by an in-house team.</p> |
| <p>Assembly programmers are rare and expensive to hire. Using assembly language |
| is inherently less productive than high level coding. Being able to program in |
| C would boost productivity and reduce costs, but with such a small user base, |
| spending years on developing a full LLVM compiler tool chain cannot be |
| justified.</p> |
| <p>But a full C/C++ compiler tool chain is not needed. C is sufficient, and the |
| well defined user base means only a limited feature set is required. In this |
| talk I will describe the development of a LLVM tool chain for C for a 16-bit |
| word-addressed Harvard architecture DSP. The work required 120 days of |
| engineering effort in 2016/17, and also included the implementation of a |
| CGEN-based assembler/disassembler, GDB and newlib C library. The LLVM work |
| included adding support for 16-bit integers and the whole tool chain was |
| regression tested using both the LLVM lit tests and GCC C regression test |
| suite. The tool chain has been in production use for the past 12 months.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_11"> |
| <b>Measuring the User Debugging Experience</b><br> |
| <i>G. Bedwell</i> |
| <p>As compiler engineers, we (hopefully) think a lot about the the quality of |
| the debug data that our compiler produces whether that be DWARF, Codeview or |
| something else entirely. In general, we'd expect that producing more accurate |
| debug data will lead to a better quality of debugging experience for the user, |
| but how can we measure that quality of debugging experience beyond more general |
| strategies such as dogfooding the tools ourselves?</p> |
| <p>We'll present the Debugging Experience Tester tool (DExTer) and how we can |
| use it in conjunction with various heuristics to assign a score to the overall |
| quality of debugging. Using this, we can start answering some interesting |
| questions. How does clang at -O0 -g compare to clang at -O2 -g? How does |
| clang-cl compare against MSVC when debugging optimized code in Visual Studio? |
| How has the clang debugging experience changed over the years? We'll suggest |
| how can we use this information to improve the quality of the debugging |
| experience we provide and how this could be used to inform the implementation |
| of the long talked about -Og optimization level.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_12"> |
| <b>Measuring x86 instruction latencies with LLVM </b><br> |
| <i>G. Chatelet, C. Courbet, B. De Backer, O. Sykora</i> |
| <p>Instruction latencies are at the core of the instruction scheduling process |
| of the LLVM backend. This information is usually provided by CPU vendors in the |
| form of reference manuals or as direct contributions to the LLVM code base. |
| Validating and correcting this information is hard. Dr. Agner Fog has been |
| maintaining a database of latencies and decompositions for several years; his |
| approach is to carefully craft pieces of assembly and use PMUs (Performance |
| Monitoring Units).</p> |
| <p>We present a tool based on LLVM and inspired by Fog that automates the |
| process of measuring instruction latencies and infers the assignment of |
| micro-operations to ports. Our goal is to feed this information back into LLVM |
| configuration files.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_13"> |
| <b>OpenMP Accelerator Offloading with OpenCL using SPIR-V </b><br> |
| <i>D. Schürmann, J. Lucas, B. Juurlink</i> |
| <p>For many applications modern GPUs could potentially offer a high efficieny |
| and performance. However, due to the requirement to use specialized languages |
| like CUDA or OpenCL, it is complex and error- prone to convert existing |
| applications to target GPUs. OpenMP is a well known API to ease parallel |
| programming in C, C++ and Fortran, mainly by using compiler directives. In this |
| work, we design and implement an extension for the Clang compiler and a runtime |
| to offload OpenMP programs onto GPUs using a SPIR-V enabled OpenCL driver.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_14"> |
| <b>Parallware, LLVM and supercomputing </b><br> |
| <i>M. Arenaz</i> |
| <p>The HPC market is racing to build the next breakthrough exascale |
| technologies by 2024. The high potential of HPC is being hindered by software |
| issues, and porting software to new parallel hardware is one of the most |
| significant costs in the adoption of breakthrough hardware technologies. |
| Parallware technology innovation hinges on its different approach to dependence |
| and data-flow analyses. LLVM uses the classical mathematical approach to |
| dependence analysis, applying dependence tests and the polyhedral model mainly |
| to vectorization of inner loops. In contrast Parallware uses a semantic |
| analysis engine powered by a fast, extensible, hierarchical classification |
| scheme to find parallel patterns in the LLVM-IR. The technical talk proposed |
| for EuroLLVM will present the key challenges being addressed at Appentra: (1) |
| Pros and cons of developing Parallware’s classification scheme on top of the |
| LLVM-IR; (2) Parallware use of Clang and Flang to map the semantic information |
| collected in the LLVM-IR back to the source code; (3) Parallware mechanisms to |
| annotate and refactor the source code in order to produce |
| OpenMP/OpenACC-enabled parallel code.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_15"> |
| <b>Returning data-flow to asynchronous programming through static analysis </b><br> |
| <i>M. Gilbert</i> |
| <p>Asynchronous event driven simulation is an efficient mechanism to model |
| hardware devices. However, this programming style leads to a callback nightmare |
| which impairs understanding of a program’s (hw model’s) data-flow. I will |
| present a combination of runtime library and libtooling based static analysis |
| tool which returns a data-flow view to a decoupled call graph. This |
| significantly aids in program understanding and is a crucial tool for |
| understanding behavior of a large, complicated system.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_16"> |
| <b>RFC: A new divergence analysis for LLVM </b><br> |
| <i>S. Moll, T. Klössner, S. Hack</i> |
| <p>This RFC is a joint effort by Intel and Saarland University to bring the |
| divergence analysis of the Region Vectorizer (RV) to LLVM. This is part of the |
| VPlan+RV proposal that we presented at the US LLVM Developers’ Meeting 2017. |
| The divergence analysis is an essential building block in loop vectorization |
| and the optimization of SPMD kernels. This effort is complementary to the VPlan |
| proposal brought forward by Intel. The Region Vectorizer is an analysis and |
| transformation framework for outer-loop and whole-function vectorization. RV |
| vectorizes arbitrary reducible control flow including nested divergent loops. |
| RV is being used by the Impala [1] and the PACXX [6] high performance |
| programming frameworks.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_17"> |
| <b>Static Performance Analysis with LLVM </b><br> |
| <i>C. Courbet, O. Sykora, G. Chatelet, B. De Backer</i> |
| <p>Static performance analysis tools are instrumental in helping developers |
| understand and tune the performance of their computation kernels. They are |
| typically used in addition to benchmarking. This includes, for example, |
| statically evaluating the throughput/latency of a basic block or identifying |
| the critical path or limiting resources. These tools are typically provided by |
| vendors in the form of closed-source, closed-data binaries (e.g. Intel® |
| Architecture Code Analyzer [1]).</p> |
| <p>Based on the data already present in LLVM for instruction scheduling (such |
| as uops, execution ports/units, and latencies), we automatically generate |
| subtarget performance simulators with a unified API. This allows building |
| generic static performance analysis tools in an open and maintainable way.</p> |
| <p>Beyond tools to analyze code, we’ll show applications to automatic |
| performance tuning.</p> |
| <p>[1] <a href="https://software.intel.com/en-us/articles/intel-architecture-code-analyzer">https://software.intel.com/en-us/articles/intel-architecture-code-analyzer</a></p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_18"> |
| <b>Supporting the RISC-V Vector Extensions in LLVM </b><br> |
| <i>R. Kruppe, J. Oppermann, A. Koch</i> |
| <p>RISC-V is an open and free instruction set architecture (ISA) used in |
| numerous domains in industry and research. The (in-development) vector |
| extensions supplement the basic ISA with support for data parallel |
| computations. Software using them is vector length agnostic and therefore works |
| with a variable vector length determined by the hardware as opposed to |
| fixed-size SIMD registers, making software portable across a range of |
| implementations. The vector length can also vary during execution depending on |
| the requirements of the kernel being executed. The highly variable vector |
| length raises unique challenges for supporting this instruction set in |
| compilers. This talk gives an overview of the ongoing work to support it in |
| LLVM, covering the overall implementation strategy, proposed extensions to LLVM |
| IR, relation to the work for the similar Scalable Vector Extensions by Arm, and |
| the current implementation status.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Lightning_19"> |
| <b>Using Clang Static Analyzer to detect Critical Control Flow</b><br> |
| <i>S. Cook</i> |
| <p>As part of the SECURE project |
| (<a href="http://gtr.rcuk.ac.uk/projects?ref=132799">http://gtr.rcuk.ac.uk/projects?ref=132799</a>), |
| we are implementing transformations and analyses in open-source compilers which |
| reduce programmer effort and error when implementing secure applications.</p> |
| <p>This talk will discuss our work on extending the clang static analyzer to |
| detect when "critical" variables are used to affect control flow. Critical |
| variables are sensitive pieces of information that a programmer wishes to keep |
| secret (such as cryptographic keys), and their use in the control flow graph |
| can cause them to leak through side channel attacks.</p> |
| <p>Our checker searches for branches that depend on critical variables and |
| values derived from such critical variables and generates reports informing a |
| user where the value became critical in their program. We discuss our |
| experience in extending the checker to detect cases where it is the type itself |
| that is of interest rather than a particular value, as we are interested in |
| whether a variable is critical, irrespective of the value it holds at any given |
| time.</p> |
| </td></tr></table> |
| |
| <div class="www_sectiontitle" id="Posters">Posters</div> |
| <p style='text-align: right'>[<a href="#top">top</a>]</p> |
| |
| <table cellpadding="10"><tr><td valign="top" id="Poster_1"> |
| <b>Automatic Profiling for Climate Modeling </b><br> |
| <i>A. Gerbes, N. Jumah, J. Kunkel</i> |
| <p>Some applications are time consuming like climate modeling, which include |
| lengthy simulations. Hence, the coding of such applications is sensitive in |
| terms of performance. Most of the execution time of such applications is spent |
| to execute specific parts of the code. Thus, giving more time to the |
| optimization of those code parts can improve the application's performance. To |
| identify the performance aspects of the code parts, profiling the application |
| is a well-known technique.</p> |
| <p>There are many tools and options for application developers to profile their |
| applications. However, generally the profiling process provides performance |
| information for an application or parts of it. To get such information for |
| different parts of an application, some tools -e.g. LIKWID- allow the developer |
| to tell the tool which parts are intended to be profiled. Developers mark the |
| parts that they need performance information about.</p> |
| <p>In this poster, we present an effort to profile climate modeling codes with |
| two alternative methods. In the first method, we use the GGDML translation tool |
| to mark the computational kernels of an application for profiling. In the |
| second, we use Clang to mark some code parts. The same application code is |
| written with the C language and the higher-level language extensions of GGDML. |
| This source code is translated into a code that is ready for profiling in the |
| first case. For the second method, the source code is translated into a C code |
| without profiling markers. The resulting code is marked with a Clang |
| instrumentation tool. Both of the code versions that are marked are then |
| profiled.</p> |
| <p>Both methods successfully generated the profiling markers. The GGDML |
| translation tool was able to generate the profiling markers for the |
| computational kernels according to the higher semantics of the language. The |
| Clang-generated markers were driven by the Clang node types. The tested Clang |
| annotations generated in the experiments give similar results for those |
| generated by the GGDML translation tool.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Poster_2"> |
| <b>Cross Translation Unit Analysis in Clang Static Analyzer: Qualitative Evaluation on C/C++ projects </b><br> |
| <i>G. Horvath, P. Szecsi, Z. Gera, D. Krupp</i></i> |
| <p>The Clang Static Analyzer cannot reason about errors that span across |
| multiple translation units. We implemented Cross Translation Unit analysis and |
| presented the performance properties of our implementation in the last year's |
| EuroLLVM conference.</p> |
| <p>In the CTU analysis mode we usually find 1.5-2 times more potential bugs. It |
| is of paramount importance to study what are the quality (true/false positive |
| rate, path length, ...) of these reports. This year we present a poster about |
| the advancements since last year and a qualitative analysis of the reports on |
| popular open source projects using CTU.</p> |
| <hr></td></tr><tr><td valign="top" id="Poster_3"> |
| <b>Effortless Differential Analysis of Clang Static Analyzer Changes </b><br> |
| <i>G. Horváth, R. Kovács, P. Szécsi </i> |
| <p>The proposition of a new patch to the Clang Static Analyzer engine includes |
| information about the possible effects of the change. This normally consists of |
| analysis results on a few software projects before and after applying the |
| patch.</p> |
| <p>This common practice has a few shortcomings. First, patch authors often have |
| a bias towards a set of projects they are familiar with. Indeed, finding a set |
| of test projects that truly show the effects of the patch can be a challenging |
| task. Not to mention that a reviewer's request to extend the number of test |
| projects might result in a significant amount of extra work for the patch |
| author. Ideally, the reproduction and the extension of an analysis should be |
| painless, and it should be possible to display results in an easily shareable |
| format.</p> |
| <p>We present a set of scripts for Clang-Tidy and the Clang Static Analyzer to |
| address the above described issues in the hope that they will be beneficial not |
| only to analyzer patch authors, but to a wide range of developers within the |
| community.</p> |
| <hr></td></tr><tr><td valign="top" id="Poster_4"> |
| <b>Offloading OpenMP Target Regions to FPGA Accelerators Using LLVM </b><br> |
| <i>L. Sommer, J. Oppermann, J. Korinth, A. Koch</i> |
| <p>In recent versions, the OpenMP standard has been extended to support |
| heterogeneous systems. Using the new OpenMP device constructs, regions of code |
| can be offloaded to specialized accelerators. Besides GPUs, FPGAs have received |
| increasing attention as dedicated accelerators in heterogeneous systems. The |
| goal of this work is to develop a compile-flow to map OpenMP target regions to |
| FPGA accelerators based on LLVM and the Clang frontend. We explain our custom |
| Clang-based compilation-flow as well as our extensions to the LLVM OpenMP |
| runtime implementation, responsible for data-transfer and device execution, and |
| describe their integration into the existing LLVM offloading |
| infrastructure.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="Poster_5"> |
| <b>Using clang as a Frontend on a Formal Verification Tool </b><br> |
| <i>M. Gadelha, J. Morse, L. Cordeiro, D. Nicole</i> |
| <p>We will introduce ESBMC's new clang-based frontend; ESBMC is an SMT-based |
| context-bounded model checker that aims to provide bit-precise verification of |
| both C and C++ programs. Using clang as a frontend not only eases the burden of |
| supporting the ever evolving C/C++ standards (now being released every 3 |
| years), but also brings a series of advantages, e.g., warning and compilation |
| messages as expected from a compiler, expression simplifications, etc.</p> |
| <p>The frontend was developed using libTooling and we will also present the |
| challenges faced during development, including bugs found in clang (and patches |
| submitted to fix them).</p> |
| <p>Finally, we will present a short summary of ESBMC's features, and our future |
| goal of fully supporting the C++ language, and the remaining work for attaining |
| that goal.</p> |
| </td></tr></table> |
| |
| <div class="www_sectiontitle" id="SRC">Student research competition</div> |
| <p style='text-align: right'>[<a href="#top">top</a>]</p> |
| |
| <table cellpadding="10"> |
| <tr><td valign="top" id="SRC_2"> |
| <b>Compile-Time Function Call Interception to Mock Functions in C/C++ </b><br> |
| <i>G. Márton, Z. Porkoláb</i> |
| <p>In C/C++, test code is often interwoven with the production code we want to |
| test. During the test development process we often have to modify the public |
| interface of a class to replace existing dependencies; e.g. a supplementary |
| setter or constructor function is added for dependency injection. In many |
| cases, extra template parameters are used for the same purpose. These solutions |
| may have serious detrimental effects on code structure and sometimes on |
| run-time performance as well. We introduce a new technique that makes |
| dependency replacement possible without the modification of the production |
| code, thus it provides an alternative way to add unit tests. Our new |
| compile-time instrumentation technique modifies LLVM IR, thus enables us to |
| intercept function calls and replace them in runtime. Contrary to existing |
| function call interception (FCI) methods, we instrument the call expression |
| instead of the callee, thus we can avoid the modification and recompilation of |
| the function in order to intercept the call. This has a clear advantage in case |
| of system libraries and third party shared libraries, thus it provides an |
| alternative way to automatize tests for legacy software. We created a prototype |
| implementation based on the LLVM compiler infrastructure which is publicly |
| available for testing.</p> |
| <hr> |
| <p style='text-align: right'>[<a href="#top">top</a>]</p> |
| </td></tr><tr><td valign="top" id="SRC_3"> |
| <b>Improved Loop Execution Modeling in the Clang Static Analyzer </b><br> |
| <i>P. Szécsi </i> |
| <p>The LLVM Clang Static Analyzer is a source code analysis tool which aims to |
| find bugs in C, C++, and Objective-C programs using symbolic execution, i.e. it |
| simulates the possible execution paths of the code. Currently, the simulation |
| of the loops is somewhat naive (but efficient), unrolling the loops a |
| predefined constant number of times. However, this approach can result in a |
| loss of coverage in various cases. This study aims to introduce two alternative |
| approaches which can extend the current method and can be applied |
| simultaneously: (1) determining loops worth to fully unroll with applied |
| heuristics, and (2) using a widening mechanism to simulate an arbitrary number |
| of iteration steps. These methods were evaluated on numerous open source |
| projects and proved to increase coverage in most of the cases. This work also |
| laid the infrastructure for future loop modeling improvements.</p> |
| <hr> |
| </td></tr><tr><td valign="top" id="SRC_4"> |
| <b>Using LLVM in a Model Checking Workflow </b><br> |
| <i>G. Sallai</i> |
| <p>Formal verification can be used to show the presence or absence of specific |
| type of errors in a computer program. Formal verification is usually done by |
| transforming the already implemented source code into a formal model, then |
| mathematically proving certain properties of that model (e.g. an erroneous |
| state in the model cannot be reached). The theta verification framework |
| provides a well-defined formal model suitable for checking imperative programs. |
| In this talk, we present an LLVM IR frontend for theta, which bridges the gap |
| between formal verification frameworks and the LLVM IR representation. |
| Leveraging the LLVM IR as the frontend language of the verification workflow |
| simplifies the transformation and allows us to easily add new supported |
| languages.</p> |
| <p>However, these transformations often yield impractically large models, which |
| cannot be checked within a reasonable time. Therefore size reduction techniques |
| need to be used on the program, which can be done by utilizing LLVM's |
| optimization infrastructure (optimizing for size and simplicity rather than |
| execution time) and extending it with other reduction algorithms (such as |
| program slicing).</p> |
| <hr> |
| <p style='text-align: right'>[<a href="#top">top</a>]</p> |
| </td></tr></table> |
| |
| |
| |
| <!-- *********************************************************************** --> |
| |
| <div style="float: left; width:30%; padding-left: 20px;"> |
| <h2 align="center">Diamond Sponsors:</h2> |
| <div class="sponsors_diamond"> |
| <a href="http://www.apple.com"> |
| <h1>Apple</h1>Apple</a><br> |
| <a href="http://www.quicinc.com/"><img src="logos/quic-stack-version.jpg"> |
| <br>QuIC</a><br> |
| </div> |
| |
| <h2 align="center">Platinum Sponsors:</h2> |
| <div class="sponsors_platinum"> |
| <a href="http://google.com"><img src="logos/Google-logo_420_color_2x.png"> |
| <br>Google</a><br> |
| <a href="http://www.mozilla.org"><img src="logos/Mozilla.png"> |
| <br>Mozilla</a><br> |
| <a href="http://us.playstation.com/corporate/about/"><img src="logos/psf_pos.jpg"> |
| <br>Sony Interactive Entertainment</a> |
| </div> |
| |
| <h2 align="center">Gold Sponsors:</h2> |
| <div class="sponsors_gold"> |
| <a href="http://www.arm.com/"><img src="logos/Arm_logo_blue_150LG.png"> |
| <br>Arm</a><br> |
| <a href="https://www.mentor.com"><img src="logos/Mentor-ASB-Logo-Black-Hires.png"> |
| <br>Mentor</a><br> |
| <a href="http://intel.com"><img src="logos/Intel-logo.png"><br>Intel</a><br> |
| <a href="http://facebook.com/"><img src="logos/FB-fLogo-Blue-broadcast-2.png"> |
| <br>Facebook</a><br> |
| <a href="http://www.hsafoundation.com"><img src="logos/HSAFoundation-FINAL.PNG"> |
| <br>HSA Foundation</a><br> |
| </div> |
| |
| <div align="right"><i>Thank you to our sponsors!</i></div> |
| </div> |
| |
| <!-- *********************************************************************** --> |
| |
| <hr> |
| |
| <!--#include virtual="../../footer.incl" --> |