From: Michael Ellerman
> Sent: 24 January 2017 06:16
> Anton Blanchard <an...@samba.org> writes:
> >> We added:
> >>
> >> BUILD_BUG_ON(!__builtin_constant_p(feature))
> >>
> >> to cpu_has_feature() and mmu_has_feature() in order to catch usage
> >> issues (such as cpu_has_feature(cpu_has_feature(X)). Unfortunately
> >> LLVM isn't smart enough to resolve this, and it errors out.
> >>
> >> I work around it in my clang/LLVM builds of the kernel, but I have
> >> just discovered that it causes a lot of issues for the bcc (eBPF)
> >> trace tool (which uses LLVM).
> >>
> >> How should we work around this? Wrap the checks in !clang perhaps?
> >
> > Looks like it's a weakness in LLVM with inlining:
> >
> > #include <assert.h>
> >
> > #if 1
> > static inline void foo(unsigned long x)
Does making this 'const unsigned long x' help?
ISTR that making a slight difference to the instruction patterns
gcc would use.
> > {
> > assert(__builtin_constant_p(x));
> > }
> > #else
> > #define foo(X) assert(__builtin_constant_p(X))
> > #endif
...
> #define inline inline __attribute__((always_inline))
> notrace
>
> So in fact every inline function is marked always_inline all the time,
> which seems dubious.
I've had to do that in the past to get gcc to inline some small leaf functions
that were only called once.
(That was for some embedded code where I don't actually want any function calls
at all.)
To my mind 'inline' should mean 'always_inline' since you need to explicitly
stop functions being inlined even when not marked 'inline'.
David
