[PATCH] Move -fbuiltin from c.opt to common.opt and change it to common group

[Kito Cheng]

Hi Richard:

>> >> -fno-builtin is seem not only for the c family front-end, but also
>> >> used in LTO now, so move it to common.opt and change it to `Common`.
>> >
>> > Please leave it in c-family and just add LTO to the set of supported
>> > languages.  -fno-builtin isn't meaningful for other frontends
>> > and we just happen to use the flag.
>> > If then it makes more sense to move -fhosted and -ffreestanding
>> > though I don't know how meaningful those are for other frontends.
>> >
>> > Or create a "proper" flag to communicate that the middle-end
>> > should avoid creating new calls to builtins at all cost
>> > (well, that's really what -ffreestanding is about).
>>
>> -fno-builtin is meaningless for other front-end but middle-end,
>
> Well, I wouldn't say that.

Sorry for my misunderstand.

>> However `-fno-builtin` is more explicit than -fhosted and  -ffreestanding,
>> when people see the option `-fno-builtin`, they will know what this
>> option mean "do not use builtin implicitly", and most important
>>  -fno-builtin is more well known than -fhosted or -ffreestanding.
>
> But builtins _are_ used implicitely regardless of -fno-builtin!
> At least memcpy, memmove and memset are.

Are you mean the name of `-fno-builtins` is not precise enough?
or we can't disable ALL implicitly built-in function call so `-fno-builtins`
is not the best option name for solve this problem?

And I still prefer use `-fno-builtin` since it's well known:

Here is some investigate for the C library:
Many C library has add `-fno-builtin`, but only musl add `-ffreestanding`
(Sampling: glibc, uClibc, newlib, dietlibc, musl, bionic)

So if we use `-fno-builtin` then the C library can do LTO without
change in future.
(though LTO with C library is not work well today.)

>> and the flag_no_builtin is already used in gcc/lto/lto-lang.c:def_builtin_1,
>> so my patch is not first user of this option in LTO front-end.
>
> Yeah, but nothing sets that flag in LTO so it is always zero
> (so the use is bogus).

Agree.

> It's also that setting that flag dependent on a "merged" -fno-builtin
> will break TUs that use builtins.  So I fear it's not that easy.
> Hmm.
>
> I don't like all those tri-state options but I guess it would
> make sense to have for -ftree-loop-distribute-patterns for this
> case (to note it's disabled by -ffreestanding/-fno-builtin).
>
> That said - the whole way we handle option merging in LTO is
> somewhat broken and this is just an example where the current
> hacky scheme breaks down.

Yes, I understand the root cause indeed is the option merging
problem, I have tried to LTO a program with llibc.a (newlib)
and then got lots of problem for option and built-in functions.

> So maybe instead finally fix LTO option merging?
>
> There were two ideas floating around - first is to annotate
> all functions with option and target attributes as coming
> in from the individual TUs, second is to do LTRANs partitioning
> based on options and thus have different "global" options for
> different LTRANS units.

In my understand the key point is grouping by option and prevent
interaction between different group (eg. never inline or ipa-cp between
 different group).
The second idea seem more feasible at this moment since most
option in gcc still propagate by global variable, so maybe we need
to refactoring `option flags` in gcc for first idea if we doing this approach.

> Note that for selected options we already annotate struct function
> (like for -fnon-call-exceptions), eventually annotating struct
> function is more sensible than optimize or target attributes.
>
> The question remains what to do with the options explicitely
> specified at link time - this probably means we need to continue
> to distinguish flags we have to conservatively carry over from
> compile-phase and those we can safely override.
>
> Both above ideas mean that option processing would mostly move from
> lto-wrapper to lto1 (WPA phase), maybe apart from computing a
> default optimization level in case there was none specified at
> link time.
>
> Maybe you have time working towards this?  A first step would be
> to move most of the option merging code from lto-wrapper to
> lto1.

However seem both idea need to do this thing first, I will take a look
in next days :)