On Tue, Oct 01, 2019 at 10:44:43AM -0700, Nick Desaulniers wrote:
> I apologize; I don't mean to be difficult. I would just like to avoid
> surprises when code written with the assumption that it will be
> inlined is not. It sounds like we found one issue in arm32 and one in
> arm64 related to outlining. If we fix those two cases, I think we're
> close to proceeding with Masahiro's cleanup, which I view as a good
> thing for the health of the Linux kernel codebase.
Except, using the C preprocessor for this turns the arm32 code into
yuck:
1. We'd need to turn get_domain() and set_domain() into multi-line
preprocessor macro definitions, using the GCC ({ }) extension
so that get_domain() can return a value.
2. uaccess_save_and_enable() and uaccess_restore() also need to
become preprocessor macro definitions too.
So, we end up with multiple levels of nested preprocessor macros.
When something goes wrong, the compiler warning/error message is
going to be utterly _horrid_.
Now, as to whether an __attribute__((always_inline)) can or can not
be inlined...
`always_inline'
Generally, functions are not inlined unless optimization is
specified. For functions declared inline, this attribute inlines
the function even if no optimization level is specified.
Is this another instance of the compiler folk changing the rules of
already documented semantics? This says nothing about "might not be
inlined if someone passes some random combination of -f flags".
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
