You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While complex rewrites and things such as custom printers/parsers are likely going to always need C++, we have lots of operations and patterns that should be expressible in the irdl and pdl dialects (for the latter, potentially via the associated DSL PDLL).
While its arguable whether those are easier to write/read than their TableGen alternatives, they are certainly more "manipulatable/translatable" which is relevant, for example, to ease the automated extraction of dialect/op definitions and rewrite rules for formal verification (See also #817).
The main issue with IRDL in the past was that it only allowed defining dialects and ops at runtime, but now there's apparently IRDL-to-C++ which means you still get all the autogenerated C++ code assocaited with dialects and ops that we rely upon when we write our passes/etc. The main issue with PDL (and, especially PDLL) is, afaik, one of expressivness, and I'm not sure if there's been any development on this since their initial upstreaming.
The main task of this PR is to investigate which, if any, of our dialects/patterns would be expressible in IRDL/PDL(L) - whether or not we'd actually want to make that switch is probably a discussion for afterwards.
The text was updated successfully, but these errors were encountered:
So I wrote a PDLL tutorial about six months ago and I think, if not for one missing feature (support for arithmetic; I asked mgehre if any progress has been made, waiting on a response), we could feasibly convert all of our existing tablegen-based patterns (TensorExt, ModArith, and Polynomial canonicalizations).
For more complex patterns (secret, linalg kernels, etc) we would need support for regions, and possibly dialect conversion, which are big missing features. I had expressed interest in adding support for regions, but I feel it would take quite a long time.
The last time I tried looking into IRDL, I couldn't get anything to work, though I can see in the commit history a lot of new work has been done.
Currently, all our dialects and ops are defined using the TableGen-based Operation Definition Specification (ODS) and our canonicalization/folding patterns are expressed as either TableGen-based Declarative Rewrite Rules (DRR) or directly in C++.
While complex rewrites and things such as custom printers/parsers are likely going to always need C++, we have lots of operations and patterns that should be expressible in the
irdl
andpdl
dialects (for the latter, potentially via the associated DSL PDLL).While its arguable whether those are easier to write/read than their TableGen alternatives, they are certainly more "manipulatable/translatable" which is relevant, for example, to ease the automated extraction of dialect/op definitions and rewrite rules for formal verification (See also #817).
The main issue with IRDL in the past was that it only allowed defining dialects and ops at runtime, but now there's apparently IRDL-to-C++ which means you still get all the autogenerated C++ code assocaited with dialects and ops that we rely upon when we write our passes/etc. The main issue with PDL (and, especially PDLL) is, afaik, one of expressivness, and I'm not sure if there's been any development on this since their initial upstreaming.
The main task of this PR is to investigate which, if any, of our dialects/patterns would be expressible in IRDL/PDL(L) - whether or not we'd actually want to make that switch is probably a discussion for afterwards.
The text was updated successfully, but these errors were encountered: