[Mlir-commits] [mlir] [mlir] Apply the default --split-input-file marker after parsing (PR #226361)

[Fangrui Song]

MaskRay wrote:

> > This patch is the interim step while MlirOptMainConfig's options are still cl::opt.
> 
> Why would removing cl::callback be a prerequisite to the work on moving library options to .td declarations? The fact that cl::callback exists but isn't reachable/usable from the .td definitions does not seem like a limitation as far as I can tell. I would think a sequencing to land these changes would better be to first move things to .td and when there is no user left for cl::callback, then it can be removed.
> 
> Also, even if this is the right sequencing for some reason, at this point this is a very recent RFC, so landing "intermediate state" which looks like regressions is OK only if they are indeed temporary, so we should ensure the proposed plan is actually gonna move through first.

 On the RFC being recent: the problems with cl::opt (global state, static initializers, per-option overhead, options leaking into tools that don't want them) have been discussed for years, and there is broad agreement on moving away from it. Many tools have migrated to OptTable over the years.

https://discourse.llvm.org/t/rfc-declare-library-command-line-options-in-tablegen-one-struct-per-library/91877 proposes an incremental path that finally enables `llvm/lib/` cl::opt options to migrate without other drawbacks (performance, platform compatibility, etc).

The reason to remove it now rather than last is to stop new uses from appearing while the migration is in flight. The .td representation is data only (it generates a plain struct and an apply() that assigns members), so every callback use added in the interim is another site that has to be redesigned before it can move.

MLIR's ManagedStatic<struct { cl::opt ... }> pattern avoids global constructors, but not the other costs: It is still one process-wide instance, so two MLIRContexts in a process can't use different values. Every read site has to check isConstructed() and fall back to a hard-coded value when a tool didn't call `register*CLOptions()`, so each option has two defaults that can drift apart. Each member is still a full cl::opt (~190 B with a vtable and a std::function) that registers itself in the global option map when constructed; registering after ParseCommandLineOptions leaves the option silently unrecognized.

https://github.com/llvm/llvm-project/pull/226361