This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Move -fbuiltin from c.opt to common.opt and change it to common group
- From: Richard Biener <rguenther at suse dot de>
- To: Kito Cheng <kito dot cheng at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Joseph Myers <joseph at codesourcery dot com>, Richard Henderson <rth at redhat dot com>
- Date: Fri, 29 Aug 2014 09:58:27 +0200 (CEST)
- Subject: Re: [PATCH] Move -fbuiltin from c.opt to common.opt and change it to common group
- Authentication-results: sourceware.org; auth=none
- References: <CA+yXCZAFMtz1rxakrRgWC5FAg=aBj4onh=bcry2V3OyscbOtDg at mail dot gmail dot com> <alpine dot LSU dot 2 dot 11 dot 1408281222480 dot 20733 at zhemvz dot fhfr dot qr> <CA+yXCZBpFXboXtfVg-jFKt3RXgK9OTVap2QMCoMCtvr47TqNrQ at mail dot gmail dot com>
On Thu, 28 Aug 2014, Kito Cheng wrote:
> 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.
> 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.
> 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).
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.
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.
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.
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
Maybe you have time working towards this? A first step would be
to move most of the option merging code from lto-wrapper to