I think I can say that from the first glance MDL could allow better and more precise description of some non-VLIW downstream ISAs. The scope is some pipeline hazards, extra interdependencies, etc. These might be current solved via existing scheduler infrastructure, but the solutions are far from being sane.
1 Like
I will need more time to digest all the details about MDL proposal, but I was curious if MDL framework is āfeature-equivalentā to TD. For example, we extensively use relational mappings to describe instructions and their predicate/new/tmp forms in Hexagon. Are those features also supported in MDL? You mentioned you have tested on x86 and didnāt find any significant performance regressions and also noticed identical code in many cases. Thatās comforting, but have you done similar experiments on other targets.
1 Like
Its able to model everything schedules or itineraries can model, with the exception of how we model forwarding. Schedules model it, roughly, on an instruction-by-instruction basis, and Itineraries model it for each itinerary. MDL models forwarding networks as a graph of functional units - which attempts to mirror what the hardware actually does. We found that for some of the targets that model forwarding, theyāve only modeled part of the forwarding network, so we end up with minor differences when we model the entire network.
So with the exception of forwarding network modeling, MDL provides a superset of what TD can express wrt microarchitecture. The whole purpose of this integration (where we translate every schedule and itinerary for every target into equivalent MDL) was to prove to ourselves that the MDL was able to handle everything in TD. (It does.)
Yes. Note that we donāt change instructions at all, just their modeled behaviors. So instructions that get rewritten are handled properly. FWIW, the current integration translates the Hexagon TD files into MDL, and passes all but a very few lit tests (27 tests āfailā out of 1280 when using MDL). The āfailuresā are very minor (hand-checked for correctness) schedule differences, or incidental debug output differences. (Not to say there arenāt bugsā¦). Note that some of this rewriting is unnecessary in an MDL-based back-end - the instructionās description can directly deal with things like predication.
Actually, per the lit tests, weāve seen very few cases where it generates different code, which was expected since we havenāt changed any of the algorithms in the schedulers. But some of the heuristics in the MI schedulers (in particular) very occasionally are perturbed by the order of scheduling alternatives provided by TD vs MDL.
Beyond running lit tests: no, not to date. I wish there was a way to do this.
A note about Hexagon: some of the initial problems we had with Hexagon involved target-specific back-end code that dealt with things that TD couldnāt model. A good example of that is ātryAllocateResourcesForConstExtā, which is called by the Hexagon Packetizer to deal with instructions that use extra issue slots for āconstantā operands. This is something MDL can handle trivially. But since in this situation weāre working with a strict translation of TD, and TD couldnāt express it, the MDL infrastructure couldnāt deal with it directly (so we had to hack the function, with an appropriate comment).
Let me know if this doesnāt answer your questions!
1 Like
FWIW, Iāve removed the PR for now. Iāve clearly misjudged the degree of concern about external dependencies, and consequently the discussion has gotten derailed. I apologize for that.
Iāll resubmit in a few weeks after Iāve replaced the ANTLR parser generator with a conventional recursive descent parser, and perhaps a little retooling to make the development flow a bit cleaner.
In the meantime, Iām happy to discuss any questions people have about the work.
-Reid
Is MDL expected to stabilize in the near future? If there are no expected notable changes to its grammar, the value of (re-)generating parser via ANTLR drops somewhat (we can still keep the ANTLR-consumable grammar description somewhere as the āsource of truthā/reference parser).
Well, every language evolves, and I expect this one to evolve too. Regardless, Iām just writing a RD parser.
Iāve written and integrated a recursive descent parser for the MDL compiler, and replaced/removed the Antlr-based parser. There are now no Antlr/Java build dependencies in the MDL repo at GitHub - MPACT-ORG/llvm-project at all
Please take a look.
6 Likes
There were a number of questions earlier in the thread about why we created a new language. Iāve updated the introductory part of the language spec (llvm-project/llvm/docs/Mdl/MDLSpec.md at all Ā· MPACT-ORG/llvm-project Ā· GitHub) to provide some of the motivation for that decision. If youāre interested in the topic, please take a look.