This allows for the results of operations to be inferred in certain contexts,
and matches the support in PDL for result type inference. The main two
initial circumstances are when used as a replacement of another operation,
or when the operation being created implements InferTypeOpInterface.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
(first sweep, mostly looks good, just some clarifications)
mlir/docs/PDLL.md | ||
---|---|---|
729 | Are the other contexts not bound types? E.g, isn't this the only inferred case and the others bound/provided? | |
mlir/lib/Tools/PDLL/Parser/Parser.cpp | ||
83 | What about Explicit, Replacement, Inferred ? | |
2063 | Do we also need to check that the op implements the interface? | |
2776 | For a replacement don't we need this too? Or perhaps stepping up: what verification is done here and why doesn't it apply for replacement? | |
2783 | I'd make this fail: given this is an AOT tool, we could warn or fail here always rather than asserting, especially as this doesn't sound like an invariant. | |
2819 | Runtime runtime? E.g., are you thinking about dynamically registered/injected interfaces? | |
2836 | Why only check for variadic? |
mlir/docs/PDLL.md | ||
---|---|---|
729 | Technically I suppose, it depends on the context of "inference". From PDLL perspective, it is inferring the types from somewhere (even if from the MLIR level, it's using bound/provided types). The use of "inference" in PDLL is when the user doesn't explicitly provide result types. | |
mlir/lib/Tools/PDLL/Parser/Parser.cpp | ||
2063 | We handle the related verification in createOperationExpr when creating the expression, the parser here tries not to inject any of that information (given that when templates are in the mix, we might not know what the operation is here). | |
2776 | The replacement inference case only happens when there are no explicit results (we don't infer if results were explicitly provided), so we don't have anything to verify in that case. The verification here is that the structure of the result expressions matches the expected format (either single value range or matching the ODS definition). | |
2783 | It's an assert right now because there isn't a code path that would exercise the error. We don't set inference if explicit values were provided. I avoided an error because that gives the expectation that the path is expected/tested/thought out, as opposed to something that can't happen. Reworked the assert to better capture this. | |
2819 | Yes, I'm thinking of dynamically registered interfaces. We do have some instances of injecting type inference interfaces, though we could choose, I suppose, to require that the ODS definition has them. Right now we haven't been applying hard enforcement that ODS has everything defined. | |
2836 | Purely variable length result operations can have zero results, and we allow elided results lists to imply zero results. |
Are the other contexts not bound types? E.g, isn't this the only inferred case and the others bound/provided?