-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Association Dialect #173
Comments
I thought about this as well. Maybe we can simply add an optional value to an axiom and have a pass that reduces axioms with their associated values later in the compilation pipeline? We could a add a bit syntactic sugar to directly do sth like this: .axm %foo.id (x: .Nat) -> .Nat = x; Sugar for .ax %foo.id: .Nat -> .Nat = .lm (x: .Nat) -> .Nat = x; |
Opaque functions as axioms would not be enough in my case. For matrix, I want to have multiple options
For autodiff, I do not want to replace the axiom but rather in certain circumstances get an associated function (the augmented function that contains the pullback). (This is roughly equivalent to rewriting |
Ah, I see. Another contender is #90. But this still isn't enough for your autodiff example, correct? |
Yes, #90 is rewrite-mapping dialect I was referring to. |
Maybe an association dialect would be helpful.
Often, when we rewrite things, we want to replace something with a semantically equal term on another level.
The destination term can often be written (more or less) conveniently in thorin.
This is especially the case for staged lowering like present in the
autodiff
andmatrix
dialect.These associations are currently implemented using naming conventions and internals (a hack around externals that are erased).
The association dialect would keep track of associations in the thorin code and expose map on the C++ side.
No special care to quoting/reification is needed as we usually only want to associate axioms anyway.
Example:
There could also be generalized passes on associations (e.g. replace all terms in a class with their associated counterpart).
This seems like a simple way to cleverly utilize the dialect infrastructure and get away from string matching.
This dialect could be combined or extend the sketched rewrite-mapping dialect from previous discussions.
The text was updated successfully, but these errors were encountered: