Re: [lto] Adding -fwhopr

["Diego Novillo" <dnovillo at google dot com>]

On Wed, Oct 1, 2008 at 13:19, Ollie Wild <aaw@google.com> wrote:
> On Tue, Sep 30, 2008 at 3:31 PM, Diego Novillo <dnovillo@google.com> 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.