Over the years, many LLVM users have needed sophisticated program analysis passes that analyze LLVM IR. Some have wanted alias analysis passes such as Steensgaard and Anderson's while others have wanted a heap abstraction for performing backwards static slicing on values stored in the heap. Still others have asked for a call graph analysis that can resolve the targets of indirect function calls.
LLVM lacks robust implementations of such analyses. While a few implementations exist, they are maintained by small groups outside of the LLVM source tree and are not of the same quality as the LLVM code. Furthermore, core LLVM optimizations have avoided using sophisticated program analyses, reducing the incentive for creating robust implementations.
The goal of this Birds-of-a-Feather session is to bring together users of sophisticated program analysis and LLVM developers to see what users need and whether there are common interests in creating, maintaining, and using these types of analyses. Tentative questions for discussion include:
o What program analyses do LLVM users and developers need that do no exist today?
o What obstacles are there to creating robust implementations of the analyses users need?
o Are there better methods of getting the information reported by these analyses (e.g., the way Type-Based Alias Analysis side-steps the need for Anderson’s alias analysis)?
o Would such analyses benefit existing LLVM optimizations while maintaining acceptable compile-time performance?
A BoF on this topic has been held every dev meeting for the past couple of years. We’ve found these BoFs very useful in identifying the main pain points in using LLVM’s performance tracking infrastructure. Only a limited amount of effort is put into improving the infrastructure and the discussions held at previous BoFs have been very valuable in generating the best-bang-for-buck ideas. Every year, LLVM’s performance tracking infrastructure has improved substantially. Without having the previous BoFs, the improvements would have been less substantial.
Last year, the BoF mainly focussed on what was still needed infrastructure-wise to efficiently make good use of the performance data collected by performance tracking bots. A number of significant improvements have been made based on last years’ BoF discussions - but we’re not there yet: currently, it seems like the community is mostly ignoring llvm.org/perf numbers as it’s still too much effort to figure out what’s causing observed performance improvements or regressions. It seems like we’re close to having a good-enough infrastructure for many developers to start caring and actively using the performance-tracking infrastructure. Let’s discuss what improvements we really still need before we can efficiently make use of llvm.org/perf specifically and LNT-based performance tracking in general.
Profile Guided Optimization (PGO) takes advantage of the program's runtime behavior to improve optimization decisions during code generation. In this BoF, we will discuss the existing PGO facilities in LLVM, missing features and plans for addressing them.
Discuss the current state of the clang static analyzer and potential future improvements. Potential topics include, but are not limited to bug triaging and suppression, integration of the static analyzer path sensitive reports into clang tidy, scan-build improvements, improvements to the analyzer core.
Today, LLVM's C API is more or less a stable API, but we don't have very well defined policies on how this works. Some users of llvm-c want stable API interfaces into various parts of the LLVM infrasture, others want further ABI guarantees about this usage, and still others simply want a way to bind to LLVM through their language frontend’s existing FFI support for C.
If we want to improve the situation for any of these users, we need to properly understand how these APIs are being used (or abused) today. This BoF will serve to allow the various stakeholders to explain what they need so that we can design future extensions properly and come up with well defined policies on how to maintain and evolve the C API.
Since the last US developers meeting the Polly loop optimization infrastructure has significantly evolved with significant progress
in terms of usability, applicability and compile time. Several regular developers joined our team from different places of the world and several of these started to extend and use Polly in new situations. In the last years both informal Polly meetups as well as officially announced BoFs have taken place at the US developer's meeting as well as EuroLLVM and these have been of great help to coordinate our efforts. As this year several core developers are attending the US developers meeting, we will have again an official BoF to discuss
with the wider LLVM community the impact of the recent changes we made in Polly, Polly's development agenda for the next years as well as its use in the wider LLVM community. Topics of interest might be: integration of Polly into the pass pipeline, interaction with other optimizations (vectorizer, classical loop optimizations), possible uses of Polly analyses, recent compile-time reduction, new optimizations,
LLVM is rapidly gaining popularity as a compilation framework for graphics processors. We will host a Birds of a Feather session to discuss issues of interest to implementers of GPU targets in LLVM. Topics may include:
- Techniques for overcoming common challenges in adapting LLVM to GPU targets
- Future directions in LLVM to benefit GPU targets
- Opportunities for different GPU targets to share infrastructure and/or optimizations
Come discuss the new exception handling constructs LLVM, how they enable targeting the Windows and CLR personality routines, how they differ from and relate to Itanium-style landing pads, the impact that SSA/IR constraints had on the design, and future directions. This session is for anyone interested in the IR model and/or exception handling semantics and codegen.
This BoF will focus on the needs of managed language (such as Java, C#, JavaScript, and Python) and how to compile various high level features efficiently using the LLVM toolchain. Topics likely to be covered include: deoptimization and speculative compilation, frame introspection, range check/null check elimination optimizations, implicit null pointer exceptions, lazy materialization of IR during optimization, exception handling integration, and patchable code. This BoF will not cover garbage collection since there's another BoF planned for that topic.
