https://discourse.llvm.org/t/rfc-mdl-a-micro-architecture-description-language-for-llvm/66409 LLVM Discussion Forums [RFC] MDL: A Micro-Architecture Description Language for LLVM Code Generation Common Infrastructure llvm reidtatge November 4, 2022, 11:44pm #1 TL;DR: We've created a DSL and compiler for modeling micro-architecture that handles a very broad class of architectures - CPU, GPUs, VLIWs, DSPs, ML accelerators, and embedded devices. This effort grew out of a need to quickly develop and experiment with high-quality compilers and tools to facilitate rapid architecture exploration. We named the DSL "MDL" for "Microarchitecture Description Language". While being significantly more expressive than TableGen's Schedules and Itineraries used in LLVM, MDL is also more concise, and simpler to read and write while supporting a much broader class of embedded and accelerator architectures. We currently can automatically _generate _MDL descriptions for all upstream targets which are in many cases 1/10 the size of the equivalent TableGen descriptions. We've integrated this with LLVM, and are sending out this RFC because we believe it could be valuable to the larger LLVM community. \ The MDL compiler, associated tools, and documentation are available as open source (at GitHub - MPACT-ORG/llvm-project at work), and we would like to explore adding this to the LLVM project, and encourage contributions from others. Background Over the last few years, we have been using LLVM to develop a compiler backend for Google's TPU machine learning accelerators. TPUs have complex microarchitectures and pose a number of challenges that are not seen in in typical LLVM targets: * Clustered VLIW with partitioned register files. * Extremely deep pipelines with complex hazard conditions * Instructions with functional-unit-specific and/or cluster-specific behaviors + Non-trivial and/or instance-specific latencies + Complex resource usage + Functional-unit-specific register constraints * Shared/allocated encoding resources (instructions need 1...M of N resources) * Explicitly managed hardware resources (register ports, internal datapaths, busses, etc) While some of these problems manifest in a few upstream targets, this collection of problems is a superset of the problems directly addressed by LLVM - Schedules and Itineraries are simply not sufficient to model everything. Supporting this class of architecture is therefore code-intensive - it takes around 20,000 lines of C++ code to model the TPU sub-targets. This is brittle, hard to write, debug, test, and evolve over time. In contrast, the MDL description for these sub-targets is ~2,000 lines of text. Status * We've created the MDL language and compiler for describing microarchitecture details, a methodology for integrating it with TableGen files for any target, and a set of APIs that can be used in a machine-independent way to inform back-end passes such as bundle-packing, instruction scheduling, and register allocation. * To facilitate integration with LLVM, we built a tool which scrapes architectural information from TableGen files, and produces our MDL language for all upstream targets. * We've modified the CodeGen and MC libraries to (optionally) use our methodology for latency management. There is a lot more to do. For example, we plan to enhance existing back-end scheduling passes and register allocation passes to cleanly handle a larger class of embedded and accelerator architectures, based on MDL-generated information. We welcome feedback on the language design and associated tools and use model. You can find the MDL design documentation in our github repo in llvm/docs/Mdl. -Reid 8 Likes LLVM Weekly - #462, November 7th 2022 mshockwave November 5, 2022, 10:24pm #2 I wonder if this can improve the precision of MCA, given the fact that it can create a model with finer granularity (@adibiagio @RKSimon). (Also I just tried to build the repo to see how MDL looks like. In case anyone here also wants to try it, please build LLVM with RTTI) dasdibye November 7, 2022, 1:33pm #3 (post deleted by author) dasdibye November 7, 2022, 1:39pm #4 How are the VLIW instruction scheduling restrictions implemented ex: x and y cannot go into the same bundle/packet ? RKSimon November 7, 2022, 3:31pm #5 @reidtatge This looks interesting, and anything that can reduce the pain of maintaining the more complex aspects of arch modelling would be awesome. Do you have examples of the definitions that are consumed by MdlCompiler? Any reason that you use antlr4 instead of tblgen? reidtatge November 7, 2022, 3:43pm #6 It can provide more detailed information, although for current upstream targets it doesn't provide any additional information than whats already in tablegen (since the descriptions are scraped from tablegen). But you're right - we can provide a lot more inforrmation than tablegen can, and this could be used to build tools like MCA for more complex architectures. (BTW, you shouldn't have to build with RTTI, so I'm wondering why you had to do that.) reidtatge November 7, 2022, 3:56pm #7 The language is designed to allow you to describe the overall architecture in such a way that we can derive bundle-packing attributes about each instruction. In your example, if X and Y can't be bundled together, typically its because they both use a particular resource: a functional unit, an issue slot, encoding bits, or some other hardware component. You can also define abstract shared resources that allow you to define arbitrary constraints on classes of instructions. The MDL has first-class language structures for things like functional units, issue slots, and register ports, but you can define your own too. So, the MDL compiler builds a "database" of instruction behaviors, and we have a solver (in MDLBundle.h) which not only determines whether a set of instructions can be issued in parallel, but which resources each instruction in the bundle would use, what their latencies would be, and any additional register constraints that the bundling implies. There's some related reading in llvm/docs/Mdl/BundlePacking.md. Hope this helps! 1 Like reidtatge November 7, 2022, 4:24pm #8 Hi Simon. Take a look at llvm/docs/Mdl/MachineDescripitionNotes.md. It's meant to be a "users' guide" for the MDL language, and has lots of simple examples, as well as a complete grammar for the language, and a complete RISCV (generated) description. As I mentioned in the RFC this was built to handle much more complex architectures (TPUs), but unfortunately I can't publish a TPU machine description (its proprietary), which would better demonstrate the power of the language. But the docs describe most of this stuff with simple examples. If you build the repo, it will generate descriptions for AArch64, AMDGPU, ARM, Hexagon, Lanai, Mips, PowerPC, RISCV, Sparc, SystemZ, and X86 - all the targets that have Schedules and/or Itineraries. They're generated into build/lib/Target//.mdl (the same place that tablegen .inc" files are generated to). Caveat: in general, since these are generated files, they're not particularly pretty to look at, but it will give you some examples to look at. Why Antlr rather than Tablegen? It seems I ought to make a tablegen joke here, but seriously: I wanted a concise, more expressive, purpose-built language that didn't require the writer to explicitly connect a lot of information, and I couldn't find a clean way to do that in tablegen. To be honest, I also wanted a very low-touch methodology - I wasn't thinking that major hacks to tablegen was something the community wanted to see! Antrl allowed us to experiment with and build a first-class language that was much easier to use and integrate with llvm. mshockwave November 7, 2022, 4:37pm #9 # reidtatge: (BTW, you shouldn't have to build with RTTI, so I'm wondering why you had to do that.) It throws some link time errors complaining about "undefined reference: typeinfo for " when building the mdl tool. I'm not sure if this is caused by the fact that I'm using ANTLR4 4.7.2 (the one bundled with Ubuntu 20.04, I did make some tweaks in your cmake file). * Home * Categories * FAQ/Guidelines * Terms of Service * Privacy Policy Powered by Discourse, best viewed with JavaScript enabled