AaronBallman wrote: > > Because this isn't for correctness but is for performance, I think there > > isn't a pressing need to land something ASAP from the community perspective > > (or is the performance truly bad enough that you think the feature is not > > really usable without doing something?). So could you keep the temporary > > changes in your downstream until the full changes are ready upstream? > > This is not something we would do because we do not want to have a dialect of > C++ that we have to maintain the compiler for.
My point is: we also don't want a dialect of C++ for this. > Our integrates and internal compiler releases are already quite complicated, > and would very quickly become unbearable if we start carrying load-bearing > patches like this. Understandable, it would be best to avoid that. > When I mention that performance is a concern I don't mean to say that our > problem is that we are leaving 25% of compile time on the table. Our problems > are a little more severe, we are hitting compile-time limits in our remote > build infrastructure that we cannot easily lift. And while the long-term > solution involves doing something with the code rather than the compiler, > having this builtin would allow to keep the pressure off for months to figure > this out on our end. That's not really a motivation for upstream to carry a language dialect though, right? > > In some regards that helps, in other regards it expands the problem because > > now we may end up with folks relying on the -cc1 argument existing. > > I thought that `-cc1` arguments are supposed to be changing over Clang > releases and not something people can rely on? If this is not the right > mechanism to advertise "please don't use this feature, it's experimental and > subject to change", what is? Would saying "_experimental_" somewhere in the > name help a little? Any option that enables to have this timely would be > greatly appreciated. `-cc1` arguments are intended to be "internal". That doesn't mean people don't post about them on Stack Overflow, etc and use them in practice (https://sourcegraph.com/search?q=context:global+lang:Makefile+-Xclang&patternType=keyword&sm=0 as a trivial example). That said, it's not that cc1 is necessarily the wrong mechanism. It's that working around the issue in upstream is the wrong mechanism. That spends scarce community resources like reviewer bandwidth, it temporarily increases the complexity of the product, and we know we'll have over twice the work to do (instead of the community working on the fix, we're working on the workaround, the fix, and the eventual revert of the workaround). Basically, the workaround solution benefits your downstream far more than it benefits the rest of the community, which is why I'm pushing back against it. That said, I don't want to be a jerk and it's possible I'm missing something -- if you'd like to hop in a call, I'm happy to do so and can try to pull together a few more Clang maintainers for other opinions. https://github.com/llvm/llvm-project/pull/139730 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
