This is the mail archive of the
mailing list for the GCC project.
Re: -fwhopr and -flto options reorg
On Thu, Nov 11, 2010 at 4:07 PM, Jan Hubicka <firstname.lastname@example.org> wrote:
>> > We have --param lto-partitions parameter for scalability.
>> > -flto-partition is used to specify either balanced (the default user wants to
>> > keep all the time), 1to1 for testsuite testing and none for compiling everything
>> > as one partition (and consequently disabling WHOPR, too)
>> Sounds like they should be switched? Internal options --> param, and
>> useful scalability parameter --> -f option ?
> Hmm, both are bit useless to be tampered with the user. ?Our default of 32
> seems to be high enough, since WPA stage then grows to be majority of
> copmilation time (we stream way too many types and decls and do it way to
> But making the parallelizm more accessible doesn't sound like too bad idea,
> at least once we fix WPA (that will probably happen after 4.6 is out)
> I don't think we have infrastructure for named --param parameters, so it won't be able to accept
>> >> >>
>> >> >> Does -flto imply -fwpa by default or not?
>> >> > -fwpa and -fltrans are used internaly to pass down the stage of WHOPR and -flto is WHOPR now
>> >> > unless you specify -flto-partition=none, so yes.
>> >> Why using partition option to control wpa or not? Is it better to use -fno-wpa?
>> > WPA is one of stages of WHOPR and we concluded that user wants to know nothing
>> > about that. ?So -fno-wpa to turn off whole WHOPR does not sound any more
>> > intuitive to users than -flto-partition=none.
>> > -fltrans and -fwpa are not user visible in any way since they are accepted only by
>> > lto1 frontend and supplied by plugin or collect2.
>> Ideally, WPA should be detected -- not asserted. For instance, if any
>> function referenced in the callgraph for the main program does not
>> have a IL (byte code) form, and that function is not one of the
>> standard library functions, ?wpa is then off. ?In such cases, there
> I think you make wrong assumption that WPA imply whole program assumptions. It does not.
> This is reason why I don't think we should make WHOPR to be user visible as it is too
> easilly confueed with that.
> WPA is just about parallelizm of link time process - it will work in both cases.
Yes I was confused both by the option name and documentation for -fwpa:
"This option runs the link-time optimizer in the
whole-program-analysis (WPA) mode, which reads in summary information
from all inputs and performs a whole-program analysis based on summary
> -fwhole-program makes whole program assumptions and so does -fuse-linker-plugin
> where supported. I plan to make -fuse-linker-plugin default as incremental change.
This is more sane ..
> Users needs to know about both lto and whole-program, unfortunately.
> LLVM for example defaults to -fwhole-program when it finds main() function.
>> are still some limited full program analysis that can be done with
>> linker feedback -- such as global variable address exposure analysis
>> -- also applies to shared library build for hidden symbols etc.
>> If partition=none means all files are LTOed together in memory, I fail
>> to understand why it implies wpa=off.
>> Another question, what is the default for parallelism? jobserv/auto?
>> or 1? For auto, is it the number of cores available?
> 1 for the moment. ?I plan to switch it to jobserv when environemnt var is found.
> Autodetecting number of cores when jobserv is not around seems sane too. We can
> call it auto.
>> > Honza
>> >> Thanks,
>> >> David
>> >> >
>> >> > Honza
>> >> >