Qi Meeting Mar 1 2024

An Extensible Compiler

Qi Meeting Mar 1 2024

Adjacent meetings: Previous | Up | Next

Summary

We merged the modular compiler work, which allows the Qi compiler to be extensible by developers.

Background

The modular compiler work was ready and we wanted to merge it to unblock the list deforestation work as well as the benchmarking work.

Review and Merge

We discussed the PR and identified a few issues to fix. After making the necessary changes, we merged it!

We monitored coverage and benchmarks after the merge and found that (1) coverage was down to 95%, and (2) nonlocal benchmarks were showing degraded performance.

Both of these had a similar cause. Currently, with the merged PR, it is necessary to (require qi/list) in order to gain deforestation of list APIs. Since our tests don't do that, they weren't actually hitting the deforestation code which they formerly were just implicitly by virtue of using racket/list APIs. This resulted in those lines not being covered. Likewise, for nonlocal benchmarks, which explained the degraded performance. We added the necessary require and that brought coverage as well as performance back to expected levels.

We haven't yet decided if deforesting only upon (require qi/list) is the actual usage pattern we are interested in, or if we want to retain minimal deforestation of list APIs in the Qi core. This would be desirable for backwards compatibility and also seems warranted as many deforestable list APIs are part of #lang racket/base. But it could also mean that the implementations would be duplicated to some extent across two different packages (i.e qi-lib and a future qi-list). We will need to iron this out sometime before the next release.

The Compiler is Extensible!

The main reason for undertaking this work was to balance the competing goals of (1) having a lean language containing the essential general purpose optimizations, (2) optimizing specialized use cases such as large list manipulation and bespoke datatypes.

We felt that the way to achieve both of these objectives would be to provide some form of compiler extension mechanism, a "deeper" analogue to how, for a language's surface syntax, macros allow extension by users and libraries while keeping the core language small.

The modular compiler approach allows compiler extensions to live in libraries but still extend the core compiler by maintaining a compile-time registry of passes. New passes may be defined in separate libraries and registered at compile time with a numeric priority, and these passes are then undertaken by the Qi compiler in the order implied by this priority.

This achieves our immediate goals of supporting this kind of extension while also keeping the core lean. In the long term, we will continue to explore this as well as other approaches such as language composition, to support elegant and robust extension of the compiler by users, functionality which ideally could be offered to other languages via an infrastructure library like Syntax Spec.

Next Steps

(Some of these are carried over from last time)

• Incorporate the new benchmarking suite into the SDK (including Makefile targets) and CI workflows
• Review whether we can continue optimizing a single syntax node at many levels
• Preserve the source syntax through expansion in Syntax Spec.

Attendees

Dominik, Michael, Sid