On 01/10/2019 09:38, Jan Beulich wrote: > On 30.09.2019 21:16, Andrew Cooper wrote: >> Clang in particular has a habit of out-of-lining these and creating multiple >> local copies of _mfn() and mfn_x(), etc. Override this behaviour. > Is special casing the typesafe helpers then the right approach? The > fundamental idea after all is to let the compiler decide. I certainly > agree that not inlining such trivial functions despite the inline > keyword looks far from optimal, but if there's such a general issue > with clang, shouldn't we make "inline" expand to "always_inline" > uniformly?
Inline handing is a mess. We currently define inline to __inline__. Undoing this results in build failures. Linux currently defines inline to always_inline and they are desperately trying to undo this (mis)behaviour. There are a few uses of always_inline for safety purposes (the speculative helpers). Most uses of always_inline look to be workarounds for the size-of-asm bug/(mis)feature. In an ideal world, we wouldn't need it at all, but I definitely don't think that taking the Linux approach is a clever move. We definitely have some static inlines which would better not being inline. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
