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. 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. 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 lto1. Richard.
