On Tue, Aug 25, 2020 at 4:10 PM Nick Desaulniers
<ndesaulniers@xxxxxxxxxx> wrote:
>
> On Mon, Aug 24, 2020 at 10:34 AM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
> >
> > On Tue, Aug 25, 2020 at 12:57:22AM +0900, Masahiro Yamada wrote:
> > >
> > >
> > > To prevent transformation from foo() into bar(),
> > > there are two ways in Clang to do that;
> > > -fno-builtin-foo, and -fno-builtin-bar.
> > > There is only one in GCC; -fno-buitin-foo.
> > >
> > > Is this correct?
> > >
> >
> > It looked that way from previous experimentation, but...
> >
> > >
> > >
> > > I just played the optimization
> > > from printf("helloworld\n") to puts("helloworld").
> > >
> > > https://godbolt.org/z/5s4ded
> > >
> > >
> > > -fno-builtin-puts cannot prevent clang
> > > from emitting puts.
> > > Is it because clang does not support
> > > -fno-builtin-puts?
> >
> > Ugh. clang doesn't have __builtin_puts() but it optimizes printf() into
> > puts(). It doesn't have __builtin_putchar() but will optimize
> > printf("c") into putchar('c').
>
> Bah, merely a <strikethrough>flesh
> wound</strikethrough><strikethrough>compiler bug</strikethrough>rather
> long TODO in the compiler.
> https://github.com/llvm/llvm-project/blob/be2bc7d4cef2edd66c7fb74b70adf62fc68754db/clang/include/clang/Basic/Builtins.def#L943
>
> Anyways, give me a week and I'll hack through the rest of them
> https://reviews.llvm.org/D86508. Certainly made HPA's point hit home,
> that's a lot of functionality to implement or disable in an
> environment.
>
> Masahiro, are you implying that we shouldn't take the
> -fno-builtin-stpcpy patch, because Clang is inconsistent? (That can be
> fixed.) Even though -fno-builtin-stpcpy works here as intended?
> https://lore.kernel.org/lkml/20200817220212.338670-2-ndesaulniers@xxxxxxxxxx/
>
> Otherwise we need to provide an implementation of this symbol in the kernel.
> https://lore.kernel.org/lkml/20200815020946.1538085-1-ndesaulniers@xxxxxxxxxx/
>
> Please, pick your poison.
I am not a compiler expert.
Nor am I sure if I am the right person who makes this decision.
But, if so, I would choose the latter.
(implement stpcpy() in the kernel)
I was addressed last night, so
I should write up my thoughts.
I do not think -fno-builtin-stpcpy is a
general solution.
-fno-builtin-stpcpy will work for now
because only Clang implements the transformation
from 'sprintf(dest, "%s", str)' into
'stpcpy(dest, str) - dest'.
If GCC implements it some day,
we would run into a problem because
in GCC, it is not -fno-builtin-stpcpy, but
-fno-builtin-sprintf that disables that optimization.
In this regard, 'KBUILD_CFLAGS += -fno-builtin-sprintf'
would be more future-proof, but it is potentially
an overkill.
We want to disable optimization from sprintf() to stpcpy(),
but we may still benefit from the optimization from
sprintf() into something else.
Linus is uncomfortable with this kind of compiler magic.
If we take compiler's freedom away,
-ffreestanding is a big hammer to solve this problem.
If we welcome the compiler's optimization,
we should implement stpcpy(), bcmp(), and whatever
until we solve all link errors.
--
Best Regards
Masahiro Yamada
