- I've used this a lot and the order we inherit from C++ is likely to bite us. It will also be very disruptive to change later, so better to do now.
- Everywhere else in the Python API, we order arguments in order of increasing optionality, as that is what lets you produce most the nicest signatures. When I've been writing custom builders, often the results can be inferred or otherwise ommitted to produce the most usable form, but then the default builder always builds [results, operands]. This patch inverts that to match elsewhere.
- Also fixes a couple of other signature nits (making the trailing loc/ip arguments keyword only, and properly naming unnamed unary results to match the default definitions).
- Removes the prohibited word 'result' in names now that it is handled correctly.
Details
- Reviewers
ftynse mehdi_amini nicolasvasilache
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Not sure about this one... I can understand the rationale, but this starts to diverge from C++/ODS, which already has suboptimal documentation and I'm apprehensive of the complexity it might add. If we agree we want to put result types after operands, we should be doing so consistently and that could be a problem for generating builders automatically if we decide we want that.
mlir/tools/mlir-tblgen/OpPythonBindingGen.cpp | ||
---|---|---|
648 | What are the extra args we accept? |
If we can infer the type, we already generate different builders in C++. My 2c: I don't think it is worth migration there (one could argue about what is more common: having operands or being able to infer return type). Here I could see it for the more "user facing" parts, but for those we'd want to generate custom builders + not allow specifying type when you'll be inferring it (make it more difficult to create invalid ops). Now if you have set of ops where you can all infer their types, then you have consistently no return type(s) arg, else you have a mix but I can't see how one could avoid the mix.
When I was writing this, I was borderline as to whether it should be a thread of just a patch. Let me start a thread.
As discussed on discourse, we won't be going forward with this change. I've forked the things that survive in to D95320 and will do another patch to implement the "most specific builder" approach that jpienaar pointed out.
What are the extra args we accept?