This is an archive of the discontinued LLVM Phabricator instance.

[mlir][python] Swap operands/results order on default builder.
AbandonedPublic

Authored by stellaraccident on Jan 15 2021, 10:26 AM.

Details

Summary
  • 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.

Diff Detail

Event Timeline

stellaraccident requested review of this revision.Jan 15 2021, 10:26 AM

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?

Not sure about this one... I can understand the rationale, but this starts to diverge from C++/ODS <snip irrelevant> . If we agree we want to put result types after operands, we should be doing so consistently

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.

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.

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.

Rebase and fork from parents.

stellaraccident abandoned this revision.Jan 24 2021, 3:25 PM

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.