nickdesaulniers
commented
3 years ago Thanks for taking the time to write up a CFP; we'd be overjoyed to have you present at LLVM Distributors Conf 2021! If you still plan on presenting, this is a reminder to get started on your slides for next week. Once they're done, we will contact you about submitting a PDF of your slides as either a pull request to this repository or via email to the organizer. We hope to have a schedule finalized by EOW; we may iterate on the schedule based on whether presenters have conflicts. Please keep this issue open for attendees to ask questions, or close this issue if you no longer plan on attending. Reminder to keep your talk concise (15 minutes); we wont be doing time for questions in order to fit as much content as possible. Attendees should ask questions here in this github issue.
Lots of interesting topics for sure!
Title
Graphcore IPU LLVM toolchain & libraries
Author
Thomas Preud'homme thomasp@graphcore.ai (Graphcore)
Distribution
LLVM toolchain and toolchain libraries for the Graphcore IPU
Abstract
Developing AI models for the Graphcore IPU is done using the Poplar SDK which relies on LLVM libraries as well as a firmware compiled using a LLVM toolchain. The Toolchain team at Graphcore provides a distribution of those components with an entirely new backend and a custom C library for other internal teams and customers' consumption.
Providing the best platform for the fast evolving AI ecosystem comes with some challenge:
What's unique about the environment you package LLVM for?
Our target architecture has a fast evolving specification with an entirely downstream support. We also have two separate sets of users: one that use the LLVM toolchain and another one which integrate LLVM libraries into a development framework distributed to customers. Finally, the Graphcore IPU follows the ongoing freestanding proposal which libc++ does not support yet.
What makes your distribution of LLVM unique?
Graphcore IPU LLVM backend is downstream-only and has tablegen files generated from the ISA documentation. It also features a SelectionDAG unit testing mechanism and has a very simple C runtime.
What might others learn from your experience?
What could be improved in upstream LLVM to make working with it easier as a downstream packager?
Keeping more target-specific code in target-specific files is a relatively easy endeavour that would make merging from upstream easier for downstream targets. A more important effort would be to have a mechanism to inform people of non-breaking changes that both downstream and upstream code owner might take advantage of, such as new SDNode that could do with new lowering code. Finally, support for the ongoing freestanding C++ proposal would help us greatly but would require a significant ongoing effort to maintain.