I think this interface would only be a very small piece of that.
Yes. Let me give more details.
Maybe I introduced confusion by discussing both join/meet and potential
applications, and was a bit too bold in my earlier comment !
I’ll try to clarify my approach.
For background, I have been working on type inference for our dialect, in
particular with control-flow. While playing with SCF, I noticed it enforces type
equality along control-flow edges.
Some dialects may want to accept dynamic or unranked shapes, so type equality
may be an excessive constraint for them. Hence my original post, asking whether
we wanted to relax the contraint. Answers explained we likely wanted to keep
type equality in SCF; fine with me.
A couple of points came out of this:
- Types join/meet seem to be useful more generally.
- We might want to consider updating the control-flow interfaces to allow
different constraints.
My previous comment was too bold:
My intended two first uses of this would indeed be relaxation of the
control-flow interfaces (or for custom interfaces), and type inference across
control-flow.
By “type inference across control-flow”, I was referring to the problem of type
inference across control-flow for our particular use-case (more below). (I did
ask @_sean_silva if there were any plans to have a generic type inference pass,
but I understand this is far out of scope here!)
Regarding the relaxation of control-flow interfaces, I should have said I want
to look at it. I simply don’t know what can be done about it.
At this point, I am not trying to address those here. Instead it seems to me
join/meet functions are valuable on their own, and may be small step toward 2.
I have found multiple times the need to implement some form of join or meet, or
some functions that would be significantly simplified by the availability of
join/meet.
That is at a high-level for the implementation of type inference with dataflow
analysis. Or at the op level, for example to refine output type/shape for ops
with SameOperandsAndResultType/Shape. In that case operating on Type instead
of shapes is nice, because we can simply use meet to refine the type(s), and
detect an issue when getting a null type; no need to dive into the details of
the types.
Note that today there are no join/meet functions for shapes available either. A
static helper was implemented in TensorOps.cpp.
From the discussion, @_sean_silva seemed to also think it would be valuable,
hence this proposal and patch.
I haven’t seen any consideration for how you would actually make the
transformations surrounding the control flow safe, i.e. you can’t just forward
values that have different types something has to make that safe, and the type
generally can’t do that for you and neither can the control flow
operation/dialect.
I am unclear about what you mean, but will try to comment.
As I noted I have not considered what would be needed to change the control-flow
interfaces. For now, join/meet seemed valuable enough independently.
What is legal will depend on the user, so changes would require allowing
some level of configuration.
To make it clear again, I am not advocating we just change the control-flow
interfaces or SCF to just use some constraints based on join/meet.
In my particular case, the join/meet functions would just be a tool used as part
of the type inference implementation, along with the dataflow analysis. It seems
to me it will give me what I need.
Of course the analysis could discover a broken program when a join is null. But
that would similar to having mismatching types with a type equality constraint.
To conclude I think we should see if we can agree on whether join/meet make
sense on their own, or if we want to discuss any plans further. Opinions ?