efriedma added a comment. > But prior to D151587 <https://reviews.llvm.org/D151587>, we did that for C++. > Why is C special here? And prior to this patch, we did that for C++ 11+. Why > is C++ 03 special here?
I'm trying to avoid regressions. C++11 made constant evaluation a lot more complicated, so in C++11 we evaluate() every global to determine const-ness. But it's always worked that way, so there's no regression. I'm not exactly happy C++11 made everything more expensive, but fixing that is a lot harder, and not a regression. > So I feel like your feedback is pulling me in opposite directions. You want > to avoid the fast path falling back to the slow path, but improvements to the > fast path directly result in "complete parallel infrastructure" which you > also don't want. Those seem mutually exclusive to me. Is there a third > option? Am I attacking a strawman? (Regardless, I don't want to seem > unappreciative of the reviews, advice, or discussion). The primary thing that makes Evaluate/APValue slow is the fact that it has a very inefficient representation of structs and arrays. Using it to evaluate simple integer expressions is largely comparable to non-Evaluate() methods. The idea is to maintain the parallel infrastructure for structs and arrays, but not for other things. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76096/new/ https://reviews.llvm.org/D76096 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
