On Sat, 30 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. > > 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 :)
Thanks! Richard.