AaronBallman wrote: > Just that the last bit of performance
Maybe we're talking about different situations; I may have missed some context in the discussion of this PR. I didn't see this as being about the last bit of performance. It sounded like this was going to knowingly introduce a performance regression in an popular configuration (RelWithDebInfo) for developing Clang because it made for cleaner code. That's not a good tradeoff IMO. That said, different contexts might find that tradeoff worthwhile. I just think we need to be careful -- developing LLVM is already frustrating to some folks due to our resource requirements and I have anecdotal evidence that it has prevented us from gaining new contributors, so I worry about steps which make that situation worse. If it benefits end users, that's one thing. But this sounded like it primarily only benefits ourselves, which is a harder sell to me. > I'd generally recommend folks use clang for developing with LLVM anyway FWIW, that's not what I recommend. I recommend folks use whatever (supported) development environment meets their needs because that gets us the most real-world experience with things like how Clang compares to other toolchains in terms of features and behavior. I use Visual Studio as my daily driver and that has led to a number of improvements in Clang over the years, both in terms of language extension compatibility and in terms of other compiler features. (Not to suggest you are wrong to recommend using Clang! Just that it's a slightly different way of looking at how we get contributions.) https://github.com/llvm/llvm-project/pull/122366 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
