ilya-biryukov wrote: > @ilya-biryukov any chance you/your folks could test this change for > performance implications in google? It's especially helpful to CERN, but the > last iteration of this direction had some regressions that stalled out > progress on that version a few years ago, so it'd be good to help poke this > along while making sure it doesn't cause release hiccups/etc for google.
Sorry for the long reply time. I will check which ways to check compilation performance we have here. I believe we should also probably check this for correctness (which should be slightly easier than checking the performance implications) as we are hitting quite some issues related to lazy reads from modules, which have proven very hard to debug and reduce in the last years. I am slightly worried it may get worse with this change and we won't be able to compile our code because of some other existing bugs. @dwblaikie do you have any memory of what caused regressions on the last try in the first place? Do we happen to do more work for compiles with many files because we accidentally push some computations further down the dependency tree and have to duplicate it instead of reading results from some common module? https://github.com/llvm/llvm-project/pull/76774 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
