[clang] [C++20] [Modules] Introduce -fmodules-reduced-bmi (PR #85050)

[David Blaikie via cfe-commits]

dwblaikie wrote:

> > > > > @iains @dwblaikie Understood. And I thought the major problem is that there are a lot flags from clang modules. And it is indeed confusing. But given we have to introduce new flags in this case, probably we can only try to make it more clear by better documents.
> > > > 
> > > > 
> > > > So you do not think it possible to restrict the new flag to be "internal" (i.e. cc1-only) and to put some _temporary_ driver processing to handle that? (I agree that this is an unusual mechanism, but the idea is to recognise that the driver-side processing is only expected to me temporary).
> > > 
> > > 
> > > I have no idea how can we make that. We still need the users to provide something to enable reduced BMI. And I think it is symmetric to a new flag.
> > 
> > 
> > What I mean is that (a) we need the internal 'cc1' flag permanently; but (b) we do not expect to need a user-facing driver flag permanently. and (c) We want to allow users to try this out.
> > I am suggesting we could say "to try this out use -Xclang -fmodules-reduced-bmi" and have _temporary_ code in the driver to deal with the changes needed to phasing.
> > If this is not possible. then I suppose I am a bit sad that we keep saying 'there are too many modules options' - but yet still add more. however - we need to make progress, so if the suggestion here is really a non-starter .. then such is life.
> > Perhaps the second suggestion (-fexperimental-xxxxx options) could be discussed at the project level.
> 
> Got your point. But I feel the `-Xclang xxx` style or the `-fexperimental-xxx` style may make people feel, "oh, this is not ready, let's wait". Then we may lose more testing opportunity. 

That seems good to me - these are pretty experimental directions we're going in. We haven't figured out how this stuff should work long term - we are experimenting.

> Also I feel such options are symmetric to the existing one.

What do you mean by "symmetric"?

The difference @iains is trying to highlight is that adding driver flags is a long-term commitment burden - adding cc1 flags, clarifying that these are not long term supported/guaranteed parts of the interface, but a way to experiment with some things until we figure out what the long term supported interface is.

Especially if we think the long-term future is always (or, at least by default) reduced BMIs, experimenting with it under a flag until we have confidence in that direction - then maybe just changing the Clang behavior (again, perhaps with a cc1 flag to opt-out as an escape hatch that's intended to be short-term while we figure out whatever bugs lead to the need to use that escape hatch - then when we fixt he bugs and remove the flag, the people on the bleeding edge will need to remove the flag, which is fine/good - rather than leaving these weird flags around forever).





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