This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]