balazs-benics-sonarsource wrote: > > So, I think if we go with the evalbinop approach, then it should work as > > efficiently as my original proposal, while sacreficing the special cases > > that fold away the binop. I'm fine with either of the approaches. > > I scheduled a measurement for the evalbinop approach, and I expect the > > results by tomorrow the latest. > > I'm looking forward to it :) I think this evalbinop approach could be a good > compromise that eliminates the outliers without messing up the code.
I can already share that the assertion enforcing that we honor Max complexity would fire on about half of the projects in the test pool so far. This is still acceptable for us, but lessens the guarantees of the original patch where this assertion would have held. I'll do another measurement now where there is no such assert in place to see if the performance would look good, in other words that we still make overly complicated symbols but less often to the degree that we care about. In this case we would accept this patch. https://github.com/llvm/llvm-project/pull/144327 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
