efriedma-quic wrote: > If we ignore that design and run functions through the block splitting > unnecessarily, we win a combinatorial increase in required testing, a > decrease in emitted code quality (spurious extra functions), an inability to > pattern match on fprintf->vfprintf style code that happens to be in the > application already. We would get to delete the isFunctionInlinable predicate.
If we do unnecessary splitting, then run the inliner, we should end up with exactly the same thing you'd get by special-casing isFunctionInlinable functions. So that's... very slightly slower compile-time, in exchange for dropping the delicate isFunctionInlinable check. That seems worthwhile to me. There's really a lot of stuff you can easily get wrong in a check like that... for example, it looks like you forgot to check the type of the load, or whether the load is volatile. Not sure what you're referring to with the "combinatorial increase in required testing". > Related - if there's an objection to landing this as an inactive pass (only > exercised by test code) we can put it into an optimisation pipeline > immediately, it'll still remove some real world variadic calls even if the > later patches don't make it. I'm fine with off-by-default as long as we have a roadmap for enabling it at some point. https://github.com/llvm/llvm-project/pull/81058 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
