rcorcs added a comment. The way I see it, with size level for LTO, we could have a different LTO optimization pipeline for size or runtime performance. For example, we could have a different tuning for inlining, vectorization, etc. We could also use the size level to automatically enable optimizations such as HotColdSplitting, MergeFunctions, etc., instead of relying on specific enabling flags. We could also have other size-specific optimizations in the future, such as MergeSimilarFunctions (https://reviews.llvm.org/D52896).
I believe that function attributes for size are useful for optimizing cold functions that have been outlined by HotColdSplitting, for example. However, an ideal size level LTO would involve a different optimization pipeline and also a different tuning of those optimizations. For example, when optimizing for size, we could disable loop vectorization and have SLP optimizing based on the code-size cost model. We could also have MergeFunctions enabled with Os and both MergeFunctions and MergeSimilarFunctions enabled with Oz. A similar logic could be applied to other optimizations, such as Inlining, HotColdSplitting, etc. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81223/new/ https://reviews.llvm.org/D81223 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
