On Tue, 1 Apr 2014, Jan Hubicka wrote: > > > > This reworks the option to use the Enum support we have now and > > adds a =one case (to eventually get rid of one LTO operation mode, > > =none ...). I was tempted to support -flto-partition=<number> > > and get rid of --param lto-partitions (thereby also supporting =1), > > Yep, I preffer to have one switch to chose algorithm and other to set > its parameter as you do now. At the moment partitioning is quite a non-issue > since only important IPA passes works on whole thing, but that may change and > we may want to play with different partitionings. > (I have plans for that for incremental compilation and other things)
Well, partitioning is important to get a parallel build. > > but that param specifies the maximum number of partitions and > > still uses the balanced algorithm, thus the result would be > > confusing (and of little use I suppose, as opposed to =1 which should > > give you the same answer as =none). > > =none still seems somewhat useful - for setups where you do multiple parallel > compilations it will be faster than WHOPR and it helps developing IPA passes > since you do not need to worry about WHOPR complexities at start. True, but as it ends up eating more memory your multiple parallel compilations may in the end be slower if they run into swap ;) And you can do simple IPA passes just where IPA-PTA sits now - at LTRANS level. > But with the code to bring function bodies at demand, this is less important. > I believe with passmanager being bit more flexible, the code paths can be > almost completely shared. Have few patches on this and pass queue reorg for > next stage1, so will try to push them out. Yeah, it would be nice to make the flow of compilation somewhat more obvious that it is now ... Richard.
