BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Pentabarf//Schedule 0.3//EN CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALDESC;VALUE=TEXT:LLVM devroom X-WR-CALNAME;VALUE=TEXT:LLVM devroom X-WR-TIMEZONE;VALUE=TEXT:Europe/Brussels BEGIN:VEVENT METHOD:PUBLISH UID:8333@FOSDEM19@fosdem.org TZID:Europe-Brussels DTSTART:20190203T090000 DTEND:20190203T094000 SUMMARY:Roll your own compiler with LLVM DESCRIPTION:
A close look at IR code generation inside a Modula-2 compiler.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:LLVM URL:https:/fosdem.org/2019/schedule/2019/schedule/event/llvm_irgen/ LOCATION:K.4.201 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Kai Nacke":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:8382@FOSDEM19@fosdem.org TZID:Europe-Brussels DTSTART:20190203T094500 DTEND:20190203T102500 SUMMARY:Rewriting Pointer Dereferences in bcc with Clang DESCRIPTION:The bcc project [1], mostly known for its collection of Linux tracing tools, is a framework to ease the development of BPF programs for Linux. Indeed, in its recent releases, the Linux kernel can be extended with small BPF bytecode programs whose memory and fault safety is statically verified at load time. These programs are usually written in a subset of C and compiled to the BPF bytecode. To access kernel memory they must use special functions, called helpers.
The bcc framework provides Python, Lua, and C++ wrappers to install and interact with these programs, as well as syntactic sugar for the C subset. In particular, bcc allows developers to access kernel memory as easily as they would access the BPF stack. C programs are transparently rewritten at load time, before their compilation to BPF bytecode, to translate all dereferences of pointers to kernel memory (called external pointers) into calls to the appropriate helpers.
In this talk, after providing the necessary background on BPF, we will discuss bcc's use of Clang to track external pointers throughout the code and rewrite their dereferences. We will describe the problems we had to overcome with code examples and detail the limitations of the current implementation. Among other things [2], bcc performs three traversals of the AST to track external pointers across BPF programs (through persistent data structures), follows external pointers through assignments, return values, and structure members, and keeps track of their indirections levels.
1 - https://github.com/iovisor/bcc2 - https://github.com/iovisor/bcc/blob/master/src/cc/frontends/clang/b_frontend_action.cc
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:LLVM URL:https:/fosdem.org/2019/schedule/2019/schedule/event/llvm_bpf_rewriting/ LOCATION:K.4.201 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Paul Chaignon":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:8232@FOSDEM19@fosdem.org TZID:Europe-Brussels DTSTART:20190203T103000 DTEND:20190203T111000 SUMMARY:Building an LLVM-based tool DESCRIPTION:In this talk, I want to share my experience in building an LLVM-based tool.
For the last three years, I work on a tool for mutation testing. Currently, it works on Linux, macOS, and FreeBSD and the source code is compatible with any LLVM version between 3.8 and 7.0. Anything that can run in parallel - runs in parallel.I will cover the following topics:
Software release products are compiled with optimization level –O2 and higher. Such products might produce a core-file that is used for investigating cause of problem that produced it. First thing from which we start debug analysis is call-trace from a crash. In such traces most of the parameters are reported as optimized out due to variety of reasons. Some of parameters are really optimized out, but some of their locations could be calculated. Expert software developers are able to find what values parameters had at function entry point by using the technique that requires searching those values in disassembly of caller frame at place of that particular function call. Automation of such technique is described by DWARF 5 specifications and it is already implemented in GCC and GDB since 2011. The goal of this paper is to present ideas, implementation and problems that we encountered while we were working on this feature in LLVM. We will also show the improvement by presenting recovered parameters in some of the call-traces. This feature should improve debugging of optimized code built with LLVM by recovering optimized-out function parameters.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:LLVM URL:https:/fosdem.org/2019/schedule/2019/schedule/event/llvm_debug/ LOCATION:K.4.201 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Nikola Prica":invalid:nomail ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Djordje Todorovic":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:7569@FOSDEM19@fosdem.org TZID:Europe-Brussels DTSTART:20190203T120000 DTEND:20190203T124000 SUMMARY:Lessons in TableGen DESCRIPTION:TableGen is LLVM's DSL for describing intrinsics, backends' machine instructions, physical registers, machine scheduling models, and a bunch of other things. It is extremely flexible and powerful, but can also be rather aggravating. Most people who spend a significant amount of time working on an LLVM backend probably develop a love/hate-relationship with it.
The goal of this talk is to give a brief overview of what TableGen offers -- frontend, application-specific backends, generic table emission backend, idiosyncratic type system, and these days even limited functional-style programming -- and a brief introduction on how to use it. The focus will be mostly on the frontend -- that is, syntax and semantics of the TableGen DSL itself -- rather than on specific backends.
Along the way, I want to share some lessons learned and decisions made during a major refactoring of the TableGen frontend that I undertook in early 2018 to iron out many of TableGen's quirks and shortcomings that had accumulated over the years, as well as some glimpses of the advanced TableGen uses in the AMDGPU backend that motivated that refactoring.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:LLVM URL:https:/fosdem.org/2019/schedule/2019/schedule/event/llvm_tablegen/ LOCATION:K.4.201 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Nicolai Hähnle":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:8306@FOSDEM19@fosdem.org TZID:Europe-Brussels DTSTART:20190203T124500 DTEND:20190203T132500 SUMMARY:LLVM for the Apollo Guidance Computer DESCRIPTION:Nearly 50 years ago on the 20th of July 1969 humans set foot on the moon for the first time. Among the many extraordinary engineering feats that made this possible was the Apollo Guidance Computer, an innovative processor for its time with an instruction set that was thought up well before the advent of C. So 50 years later, why not implement support for it in a modern compiler such as LLVM?
This talk will give a brief overview of some of the architectural features of the Apollo Guidance Computer followed by an account of my implementation of an LLVM target so far. The shortcomings of LLVM when it comes to implementing such an unusual architecture will be discussed along with the workarounds used to overcome them.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:LLVM URL:https:/fosdem.org/2019/schedule/2019/schedule/event/llvm_apollo/ LOCATION:K.4.201 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Lewis Revill":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:8345@FOSDEM19@fosdem.org TZID:Europe-Brussels DTSTART:20190203T133000 DTEND:20190203T141000 SUMMARY:llvm.mix DESCRIPTION:Automatic program specialization is a well-formed area of computer-scienceresearch with many interesting practical applications, but to this day mostexisting specializers and partial evaluators are only applicable to one of afew high level programming languages. The reason is that developing aspecializer for a new language remains still a from-scratch endeavor, and it'shard.
It is the lack of general-purpose flexible program specialization tools thatoften leads projects to creating custom just-in-time compilers for theirspecific use cases. These compilers, even if based on mature compilerinfrastructures such as LLVM's, immediately become way harder to develop andmaintain than simple interpreters they make obsolete. In many cases, however,program specialization could bring the proverbial 80% of the benefits for afraction of the cost, while maintaining simplicity and testability of theoriginal design.
It is our belief that developing a specializer for a new language should be aseasy as adding some supporting syntactic and semantic definitions to alanguage front-end and reusing an existing specializer in the middle end.
Such a language-independent specializer preferably has to:
We will present the design and the prototype implementation of amulti-stage offline specializer generator that ticks most of these boxes. Thegenerator is based on LLVM and runs in compile time along with the compilationof a source program. It is controlled by intrinsics and function and parameterattributes in LLVM IR. Being developed in the middle-end of the LLVMoptimizer, the specializer generator can be used with any language front-end.We will talk about some elements of its design, its limitations, and ways toimprove.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:LLVM URL:https:/fosdem.org/2019/schedule/2019/schedule/event/llvm_mix/ LOCATION:K.4.201 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Eugene Sharygin":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:7763@FOSDEM19@fosdem.org TZID:Europe-Brussels DTSTART:20190203T141500 DTEND:20190203T145500 SUMMARY:SMT-Based Refutation of Spurious Bug Reports in the Clang Static Analyzer DESCRIPTION:I will present a new option added to the clang static analyzer (CSA) to refute false bug reports, using satisfiability modulo theory (SMT) solvers. In this talk, I will:
(1) give a general overview of the CSA, how it works and its limitations;
(2) show how we extended the existing heuristics to remove spurious bug reports: path constraints produced by CSA are encoded as SMT problems, SMT solvers precisely check them for satisfiability, and bug reports (whose associated path constraints are unsatisfiable) are removed;
(3) show the evaluation of our refutation algorithm when analyzing twelve widely used open-source projects;
(4) show how to set up an automated testing environment using scripts provided by the CSA infrastructure. As an example, I will show how to set up the twelve projects used to evaluate our refutation algorithm: https://github.com/mikhailramalho/analyzer-projects.
The target audience of this talk is anyone interested in learning more about the clang static analyzer and in analyzing their C/C++/ObjectiveC projects.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:LLVM URL:https:/fosdem.org/2019/schedule/2019/schedule/event/llvm_smt_csa/ LOCATION:K.4.201 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Mikhail Gadelha":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:8105@FOSDEM19@fosdem.org TZID:Europe-Brussels DTSTART:20190203T150000 DTEND:20190203T154000 SUMMARY:What makes LLD so fast? DESCRIPTION:One of the main features of LLD, the LLVM Linker, is its high performance, frequently outperforming existing linkers by a substantial margin. In this presentation we'll take a look at why this might be? Starting with a brief description of the linker and what it must do, we'll look at how LLD approaches the problem, compare and contrast with other open source linkers and see how it performs on a selection of programs. We'll conclude by looking at what you might be able to take from LLD's architecture, implementation, and development into your own programs.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:LLVM URL:https:/fosdem.org/2019/schedule/2019/schedule/event/llvm_lld/ LOCATION:K.4.201 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Peter Smith":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:8343@FOSDEM19@fosdem.org TZID:Europe-Brussels DTSTART:20190203T154500 DTEND:20190203T162500 SUMMARY:Compiling the Linux kernel with LLVM tools DESCRIPTION:The Linux kernel codebase has co-evolved with GCC and binutils over its lifetime, but LLVM is now capable of producing production ready Linux kernels. Come learn what some of the challenges were in porting the codebase from GCC/binutils to Clang/LLVM, and what the latest efforts are in both codebases to work towards this goal.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:LLVM URL:https:/fosdem.org/2019/schedule/2019/schedule/event/llvm_kernel/ LOCATION:K.4.201 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Nick Desaulniers":invalid:nomail END:VEVENT BEGIN:VEVENT METHOD:PUBLISH UID:8206@FOSDEM19@fosdem.org TZID:Europe-Brussels DTSTART:20190203T163000 DTEND:20190203T170000 SUMMARY:It was working yesterday! Investigating regressions with llvmlab bisect DESCRIPTION:Investigating the source of correctness of performance regressions can be a very challenging and time consuming process. In this talk, I’m going to present an introduction to automated LLVM/clang bisecting with llvmlab bisect. Examples will be demonstrated using a Raspberry Pi board.
CLASS:PUBLIC STATUS:CONFIRMED CATEGORIES:LLVM URL:https:/fosdem.org/2019/schedule/2019/schedule/event/llvm_bisect/ LOCATION:K.4.201 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;CN="Leandro Nunes":invalid:nomail END:VEVENT END:VCALENDAR