On Wed, Oct 1, 2008 at 13:19, Ollie Wild <[EMAIL PROTECTED]> wrote: > On Tue, Sep 30, 2008 at 3:31 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: >> >> -flto: as described above. >> -fwhopr: similar to what -fwpa does today, but it is accepted by the >> driver and can take either source code or object code. In this case, >> we'd move -fwpa and -fltrans to be an lto1-only flag. > > Sounds reasonable. Just to clarify, are you thinking of -flto and -fwhopr > as mutually exclusive options, or is -fwhopr just an additional mode of > -flto.
I think the only time where both -flto and -fwhopr are virtually identical is in the LGEN phase. So, $ gcc -c -flto file.c should be the same as $ gcc -c -fwhopr file.c Though, I think this may not even be true long term, at some point we may want to do different things for both. The case that really matters is the actual link phase: $ gcc -o binary -flto *.o vs $ gcc -o binary -fwhopr *.o So, I'm leaning towards making them mutually exclusive always. > If the latter, what does being able to "take either source code or > object code" mean? Well, simply that -fwpa should only be accepted by lto1, and lto1 does not take source code, only .o files with GIMPLE in them. Perhaps the distinction is not important, as the driver can always call the corresponding front end to generate gimple before calling lto1 (as we do now) , but the multiplicity of LTO flags may be confusing for the user: -flto, -fwhopr, -fwpa, -fltrans. The last two are really only meaningful when calling lto1, so I would simply not accept it at the driver level (i.e., gcc -fwpa *.c would error out). Diego.
