pliron
pliron copied to clipboard
vaivaswatha
An Extensible Compiler IR Framework
For a while now, because `pliron-llvm` requires a local LLVM installation, and docs.rs does not have this, the doc build has been broken. Reference: https://docs.rs/crate/pliron-llvm/0.9.0/builds
Interesting and ambitious project! Do you have any driving use cases for this? Or is currently a side project? I didn't see mention of this in the Wiki or Issues,...
### Problem Statement The current [Pliron Declarative Syntax Specification](https://github.com/vaivaswatha/pliron/wiki/Declarative-Syntax-Specification) presents the following pain points: 1. Inconsistent Syntax: Disparate syntax between operations/types/attributes (e.g. `#[def_op]` vs `#[def_type]`), appearing fragmented 2. Verbose Trait...
The walker functions require a `ctx: &Context` argument for self use (to iterate over the graph entities). Additionally, the callbacks can take either `&Context` or `&mut Context`, depending on the...
Similar to the discussion [here](https://discourse.llvm.org/t/rfc-add-auxiliary-field-for-per-pass-custom-data-to-basicblock/80229), to associate arbitrary data with `Operation`s (or `Type`s) in analyses / transforms, we currently need to use a hash table (such as `FxHashMap`). Providing an...
I'm doing dialect conversion in OmniZK, so I'm drafting a pass infrastructure in pliron that resembles MLIR's. I'm using mostly the same names for types and functions. It's still WIP...
See Rust API naming [guideline](https://rust-lang.github.io/api-guidelines/naming.html#getter-names-follow-rust-convention-c-getter). Also add getter methods as needed, such as for various `self_ptr`s etc, since those fields are crate visible only.
To support moving the contents of a list b/w containers while maintaining the parent (container) pointer. This makes it straighforward to support operations such as [take_body](https://github.com/llvm/llvm-project/blob/185b81e034ba60081023b6e59504dfffb560f3e3/mlir/include/mlir/IR/Region.h#L241). In LLVM this is...
The only reason it exists is because we need a `ParserFn` to be stored in `Dialect::ops`, and I couldn't figure out a way to store a pointer to a function...
To avoid adding pliron's dependencies (`intertrait`, `linkme`, `indent`, `paste`, `inventory`) manually when using pliron.