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