dwblaikie 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.
Looks like we were talking about whether MSVC constant evaluated strlen & whether we should workaround it not doing that. It's a bit of an abstract discussion - since it seems the premise isn't true (MSVC did manage to compile the strlen to a constant in at least a simple example linked on godbolt earlier). But even if it were true - I think there's some line where we'd say the extra performance on MSVC isn't worth the extra complexity to the codebase. I guess we don't have any concrete numbers on the abstract question (what such a missed optimization would cost, since it doesn't appear to exist in reality) - but my balance for that is fairly strongly tipped in favor of avoiding that complexity and for folks building LLVM with MSVC to see some perf cost for it. How much perf cost is too much? How much code complexity is too much? Don't know. > > 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.) I'm mostly OK with that too (though you can use clang in VS, right?) but hope we don't end up complicating the codebase substantially to improve performance in that situation. That it works, yes, important, that it performs usably, yes, important. Appreciate the perspectives, though - bit surprised/good to understand the diversity of perspectives. 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
