On Thu, Oct 3, 2019 at 7:29 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Oct 3, 2019 at 10:24 AM Masahiro Yamada > <yamada.masahiro@xxxxxxxxxxxxx> wrote: > > > > I just want to annotate __always_inline for the case > > "2. code that if not inlined is somehow not correct." > > Oh, I support that entirely - if only for documentation. > > But I do *not* support the dismissal of the architecture maintainers > concerns about "does it work?" and apparently known compiler bugs. > > > Again, not saying "use a macro". > > Other people did, though. > > And there seemed to be little balancing of the pain vs the gain. The > gain really isn't that obvious. If the code shrinks by a couple of kB, > is that good or bad? Maybe it is smaller, but is it _better_? I think both positions that people have shown are important to take into account. We should minimize our usage of macros wherever possible and certainly not write new ones when another solution is available. But we should *also* minimize our dependence on code that "must-be-inlined" to work as much as possible. In particular, I think we should allow to use __always_inline only if it doesn't work otherwise, as an alternative before trying the next worst solution (macros). And avoid using only "inline" when we actually require inlining, of course. And the reasoning for each usage of __always_inline should have a comment (be it "bad codegen", "performance tanks without it", "compiler X <= 4.2 refuses to compile"...). Which is also useful for compiler folks to grep for cases to improve/fix in their compiler! Cheers, Miguel
