This is an archive of the discontinued LLVM Phabricator instance.

Expose a convenient registerCLOptions() for MlirOptMainConfig
ClosedPublic

Authored by mehdi_amini on Feb 25 2023, 1:34 AM.

Details

Summary

This allows for downstream *-opt tools to stay always aligned with the options
exposed by mlir-opt.
It aligns the "generic" options with the more "components" ones like the
pass manager options or the context options.

Diff Detail

Event Timeline

mehdi_amini created this revision.Feb 25 2023, 1:34 AM
mehdi_amini requested review of this revision.Feb 25 2023, 1:34 AM
rriddle accepted this revision.Feb 27 2023, 12:24 PM
rriddle added inline comments.
mlir/lib/Tools/mlir-opt/MlirOptMain.cpp
49

The use of static+External storage makes me feel weird, but seems fine given this situation.

237–239
interleave(registry.getDialectNames(), llvm::outs(), "\n");

?

This revision is now accepted and ready to land.Feb 27 2023, 12:24 PM
This revision was landed with ongoing or failed builds.Mar 6 2023, 6:17 AM
This revision was automatically updated to reflect the committed changes.
mehdi_amini marked an inline comment as done.
mehdi_amini added inline comments.Mar 6 2023, 6:17 AM
mlir/lib/Tools/mlir-opt/MlirOptMain.cpp
49

Made this a bit more explicit in a comment.

237–239

Done (note it was pure code motion)

gflegar added a subscriber: gflegar.Mar 6 2023, 8:55 AM

This seems to cause mlir-opt to hang when passed the --show-dialects option. Ran it through bazel:

bazel run --config=generic_clang @llvm-project//mlir:mlir-opt -- --show-dialects

Though I would be surprised if this is related to the build system.

Ah, the --show-dialects option is no longer a stand-alone thing, but an additional printout, where you could also do other things. So I guess in my example it's still waiting for some IR as input.

Was this an intentional change?

This seems to cause mlir-opt to hang when passed the --show-dialects option. Ran it through bazel:

bazel run --config=generic_clang @llvm-project//mlir:mlir-opt -- --show-dialects

Though I would be surprised if this is related to the build system.

Try ctrl+D after :)

I changed the behavior in that we still process the input file instead of aborting, I can either exit as before or add a message saying "waiting on input, try ctrl+D to abort".

Ah, the --show-dialects option is no longer a stand-alone thing, but an additional printout, where you could also do other things. So I guess in my example it's still waiting for some IR as input.

Was this an intentional change?

Indeed it was, I had landed previously https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Tools/mlir-opt/MlirOptMain.h#L103 ; but somehow in all my handling of my internal stack of patches didn't reflect it in the command line option description/behavior in the same patch...

Right, any convenient ways to just get a list of loaded dialects from a script. mlir-opt --show-dialects --version doesn't work (I guess version is processed before we get to --show-dialects), and echo "" | mlir-opt --show-dialects is a weird thing to have.

Note these are registered dialects and not loaded ones

Yes, "registered" is what I meant.

But a related question here: what happened to preloadDialectsInContext? This disappeared as a flag, and is now an unused function parameter if I'm reading this correctly? Was this also intended?

Submitted https://github.com/llvm/llvm-project/commit/f2cdccc034d0696f186f55d6826dd6ac40e4d3d5 for now that restores the preloading behavior, and fixes the test that was failing in our internal configuration. If we really need to support running commands that expect to be given an EOF input to work, we can work on our internal lit runner to support that, but I would prefer to have a heads-up for that before.

If we really need to support running commands that expect to be given an EOF input to work, we can work on our internal lit runner to support that, but I would prefer to have a heads-up for that before.

That isn't actually how upstream development work: you have to handle this kind of things in your own fork and not push "anything" upstream for your specificity. Your commit above is just not warranted IMO as it does not fix any upstream problem. Please get reviews in these kind of things!

Your commit above is just not warranted IMO as it does not fix any upstream problem.

So you're saying that making preloadDialectInContext an unused parameter was an intentional change?
And that relying on passing empty strings as stdin from lit, even though it's a bug hazard (https://discourse.llvm.org/t/lit-runner-passing-empty-stdin-to-tool-makes-incorrect-tests-pass/65672) is also desired?

From my perspective, both of these were fixing 1-line upstream bugs that were just not detected by upstream testing. If you think they are desired features, feel free to revert my change.

Your commit above is just not warranted IMO as it does not fix any upstream problem.

So you're saying that making preloadDialectInContext an unused parameter was an intentional change?

No it wasn't, thanks for noticing this. But unless a *bot* or a test is actually broken upstream, there is no urgency to push anything and the echo "" | addition seems quite unusual to me.
That is: we need to fix things, either by reverting my patch or through a fix forward, but your downstream situation alone can't be justify an "urgency" from this point of view: we can take the time to iterate on a review and decide what to do (also in general that includes adding tests for the missing coverage).

And that relying on passing empty strings as stdin from lit, even though it's a bug hazard (https://discourse.llvm.org/t/lit-runner-passing-empty-stdin-to-tool-makes-incorrect-tests-pass/65672) is also desired?

From my perspective, the lit behavior is the only environment that define what is and isn't broken upstream. The fact that you have a proprietary emulator of lit that does not match its behavior does not point at a "bug" with a test upstream.
This is independent of defining whether lit current behavior is desired or not.

From my perspective, both of these were fixing 1-line upstream bugs that were just not detected by upstream testing. If you think they are desired features, feel free to revert my change.

I don't think there is an urgency to revert, but note that "fixing bugs" without tests does not seem right in the first place to me. Also if there is no urgency, we likely would want this to be reviewed (by someone who isn't maintaining Google's fork possibly).