I think maybe you're confused; those functions do not appear to use __builtin_constant_p, which is the issue at hand. Clang's optimizer is of course not a complete joke...it can perfectly well optimize functions after inlining in order to not generate "shit code gen".
GCC, however, mixes up the concept of a C "constant expression" with the results of running optimization passes such as inlining for its definition/implementation of __builtin_constant_p. Clang does not, and quite likely will not ever, do that. That said, I do believe there are ongoing discussions as to how to best provide a useful alternative which is less semantically strange, and not too difficult for to conditionally adopt for a gcc/clang-compatible codebase such as the kernel. On Thu, Apr 5, 2018 at 3:20 AM Peter Zijlstra <pet...@infradead.org> wrote: > On Wed, Apr 04, 2018 at 04:31:11PM -0700, Matthias Kaehlcke wrote: > > From some experiments it looks like clang, in difference to gcc, does > > not treat constant values passed as parameters to inline function as > > constants. > Then you're also missing a heap of optimizations in code like > rb_erase_augmented() which is specifically constructed to take advantage > of constant propagation like that. > Other sites where we expect that to happen is __mutex_lock_common(), > __update_load_sum() and a bunch of others. There isn't strictly a bug > here, but not doing that constant propagation will still result in shit > code gen.
