NagyDonat wrote: > Let me know if you means something like this when you referred to "you can > insert one more early return".
Yes, I thought about something like your code example. > > If you really want to bother with performance improvements that > > specifically target this 0.05% of the entrypoints, then you can insert one > > more early return here at the beginning of `evalBinOp` to skip some > > calculations if you encounter a `SymbolOverlyComplex`. > > This is the point. I don't think I can special case these because the > computations still make sense to do. > [...] > Btw this would solve the performance problem (at least on the sample I > shared), and it's technically a correct implementation, but I still find it > unfair. The whole "place a limit on symbol complexity" logic is a fundamentally _unfair_ heuristic that stops some calculations that "make sense" and are theoretically similar to other calculations. Generally speaking, I'm trying to follow the dichotomy that: - The normal, commonly occurring situation should be handled by effective and elegant code that runs quickly and produces many useful and accurate results -- even if this requires lots of code complexity. - The rare corner cases should be short-circuited by simple logic, sacrificing theoretical elegance and accepting false negatives. (Even some performance hits are acceptable if they are overall negligible.) 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
