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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
