This is an archive of the discontinued LLVM Phabricator instance.

[mlir-opt] Add '-p' as an alias for '-pass-pipeline'
ClosedPublic

Authored by rkayaith on Nov 3 2022, 11:34 AM.

Details

Summary

The pipeline strings have been getting more verbose over time, adding an alias for the option should help improve the ergonomics a bit.

Diff Detail

Event Timeline

rkayaith created this revision.Nov 3 2022, 11:34 AM
Herald added a project: Restricted Project. · View Herald Transcript
rkayaith published this revision for review.Nov 3 2022, 12:24 PM
rkayaith edited the summary of this revision. (Show Details)
rkayaith added reviewers: mehdi_amini, bondhugula.
rriddle accepted this revision.Nov 3 2022, 12:27 PM
This revision is now accepted and ready to land.Nov 3 2022, 12:27 PM

I'm not sure about this: isn't there a high risk of conflicts with another CL option named -p?

I'm not sure about this: isn't there a high risk of conflicts with another CL option named -p?

We could consider prefix here (which would match the model for our other commands). I think it would be nice to have simpler syntax here, though the library situation makes it slightly tricky I suppose.

rkayaith added a comment.EditedNov 3 2022, 12:35 PM

I'm not sure about this: isn't there a high risk of conflicts with another CL option named -p?

It's registered with llvm::cl::DefaultOption, which should allow other options to shadow this one: https://llvm.org/docs/CommandLine.html#miscellaneous-option-modifiers
And when I tried that out locally it seemed to work.

Another option would be making PassPipelineCLParser::passPipeline public and only registering the alias in mlir-opt

rriddle added a comment.EditedNov 3 2022, 12:37 PM

I'm not sure about this: isn't there a high risk of conflicts with another CL option named -p?

It's registered with llvm::cl::DefaultOption, which should allow other options to shadow this one: https://llvm.org/docs/CommandLine.html#miscellaneous-option-modifiers
And when I tried that out locally it seemed to work.

Another option would be making PassPipelineCLParser::passPipeline public and only registering the alias in mlir-opt

We could also have an optional "registerAliases" or similar method on PassPipelineCLParser that could be called by users that want easier args. Then, users could specify what they want as alias, which might be nice anyways.

To me there is diminish return to the added complexity, and I'm not sure this is all pulling its weight.

rkayaith updated this revision to Diff 473044.Nov 3 2022, 2:54 PM
  • slightly different approach

The alias name is now an argument to the PassPipelineCLParser constructor so users can configure it, and it's now opt-in so this no longer affects other PassPipelineCLParser users

I think this should resolve the concerns about option name conflicts, and I don't think it adds significant complexity here.

This revision was automatically updated to reflect the committed changes.