Date & Time
Wednesday, November 17, 2021, 9:30 AM - 10:30 AM
Name
Quick Talks
Description

1) Charting CIRCT: the present and near future landscape
2) fp-model : single option floating point configuration
3) Clang vs. GCC for SPEC on AArch64
4) Unaddressable and opaque values: WebAssembly takes a hint from SVE and OpenCL
5) libclcxx: C++ libraries for OpenCL
6) Compilation databases: how to help a clang-based tool to understand your compile commands

Session Type
Quick Talks
Abstract/s
1) Charting CIRCT: the present and near future landscape - In the post-Moore’s law era, application-specific hardware accelerators have become necessary to continue the computing power trend. In the next few years, performance-oriented software engineers will likely have to pick up some hardware design skills. Currently, however, the obtuse languages and tools present a significant hurdle. The CIRCT project aims to bust through that hurdle via innovation and higher quality tools including support for higher-level design languages like Chisel; an advanced hardware “linker”; hardware synthesis from software-oriented dialects; and faster simulation, just to name a few of the subprojects. If you have been frustrated by hardware design in the past, this talk is for you. 2) fp-model : single option floating point configuration - This talk will provide an overview of the 'fp-model' concept. The fp-model is intended as a way to organize the various floating point controls into a small number of configurations that represent the most common usage models. It is implemented as a command line option in clang, but it could easily be extended to other front ends. 3) Clang vs. GCC for SPEC on AArch64 - The SPEC benchmarks are still widely used to evaluate the performance of computer systems. We found that Clang was more than 10% behind GCC on AArch64 for the integer subset of SPEC2016 on which we will focus. We will present an overview of the reasons why we were behind so much, what we have already fixed (we are now 7% behind), and what we are on planning to address to reach parity with GCC. While we target AArch64, most of our work concentrates on target independent IR passes and loop optimisations and thus our findings and ideas should be relevant for all other targets. 4) Unaddressable and opaque values: WebAssembly takes a hint from SVE and OpenCL - WebAssembly is a weird machine. One of its weird features is _opaque values_, for example a reference to a garbage-collected object from the host web browser, perhaps allocated by JavaScript. How could we allow LLVM to define a function that takes such a value as an argument? How would we represent this object whose size is unknown both at compile-time and at run-time? This talk presents our work to support opaque values in Clang and LLVM, using a combination of concepts inspired from SVE and OpenCL. 5) libclcxx: C++ libraries for OpenCL - With the advancement of C++ for OpenCL kernel language support in clang developers targeting GPUs or other accelerators can now take advantage of many high-level C++ language features to program the devices supporting the OpenCL standard. However, one of the biggest limitations remains to be the support of the standard libraries from C++. We would like to present our journey from the investigation to productizing the first standard C++ libraries for OpenCL that are now hosted in libclcxx project on GitHub. In this work we have provided support of type traits for OpenCL with all features from C++17 as well as new features for OpenCL. Instead of starting the development from scratch, the goal of this work is to reuse the functionality from the existing C++ libraries and we have selected libcxx libraries from the LLVM project towards this goal. We will describe how we enabled type traits for OpenCL and also how we used them to add new OpenCL-specific traits for vector types, address spaces, and other special types. To assess the quality of our implementation we have reused many of the standard type trait tests from libcxx as well as introduced additional tests that have been developed along with the new features. At the end, we would like to briefly outline the investigation of other libraries, e.g. algorithms, and discuss how to align the development with libcxx to allow minimal divergence while porting more functionality to OpenCL accelerators in the future. 6) Compilation databases: how to help a clang-based tool to understand your compile commands - Clang-based tools need a compilation database to get a project files and specific build options for each file. We'll talk about existing compilation database solutions, what problems you can face while using them and how to fix and adjust a compile command inside a clang-base tool. We'll look at situations in which you might need your own compilation database and what changes need to be made to support your own compilation database.