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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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?
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".
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.
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.
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!
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.
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).
The use of static+External storage makes me feel weird, but seems fine given this situation.