> >> This won't play well with LTO since fplt will become another global flag > >> while > >> it affects codegen. > > > > I know Richi explained this to me in the past, but I can't remember the > > details of why this is bad. Can you walk me through it again? > > > > I have proposed a different approach: > > https://gcc.gnu.org/ml/gcc/2015-05/msg00086.html
THe RELAX_PC* approach looks indeed interesting (I still need to catch up with the thread), but to answer Jeff's question. With LTO we need to handle stuff like gcc a.c -fplt -flto -c -O2 gcc b.c -fno-plt -flto -c -Os gcc a.o b.o -flto and generaly we would like to mimmic as closely as possible what happens with non-LTO builds. That is functions originating from a.c should be -O2 optimized with PLT and functions from b.c should size optimized w/o PLT (wich makes cross module inlining fun). To do so we now attach implicit optimization/target node to each function that stores the flags used to build the unit. optimization nodes contains only those flags that are defined as Optimization. So in general if we have a flag that is about function codegen and we are able to produce function with different values of the flag in one unit, we really want to mark it as Optimization (and decide what we want to do about inlining across the flag boundary). Not all flags works like this, for example -fPIC is a global flag and then there is Richi's code in lto-wrapper that reados those options from all .o files first and somehow chose the prevailing one for the whole program. In longer term we want to eliminate as many as possible of those global flags (for exmaple -m32 can stay global as you can not mix it with -m64) and also to explicitely represent some of the flags in IL, so inlining across boundaries works as expected. Honza > > > -- > H.J.
