This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR lto/41528] Add internal documentation in doc/lto.texi
On Mon, Nov 15, 2010 at 11:14 PM, Xinliang David Li <davidxl@google.com> wrote:
> On Mon, Nov 15, 2010 at 1:55 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Mon, Nov 15, 2010 at 5:47 PM, Diego Novillo <dnovillo@google.com> wrote:
>>> On 10-11-14 22:57 , Xinliang David Li wrote:
>>>
>>>> cc1, cc1plus, f951, and lto1 -- where does '1' here mean? It always
>>>> got me thinking where cc2/lto2/... is.
>>>
>>> Lost in the mists of tradition. ?IIRC, the '1' used to distinguish it from
>>> 'cc', the driver (others may remember the true reason, I'm too young ;). ?We
>>> are creatures of habit.
>>>
>>>> WHOPR --- the Whole part is not accurate -- it can be any part of the
>>>> whole program. The 'Whole Program' should be 'the set of IL units' to
>>>> be more exact.
>>>
>>> Naturally. ?This is the usual assumption. ?Whole refers to the whole set of
>>> files presented to the compiler. ?If the user is withholding files, there's
>>> little the compiler can do about that, short of guessing. ?I'll add a note
>>> on the semantics of 'whole' at the start of the document.
>>>
>>>>> +Currently, GCC does not support combining LTO object files compiled
>>>>> +with different set of the command line options into a single binary.
>>>>> +At link-time, the options given on the command line and the options
>>>>> +saved on all the files in a link-time set are applied globally. ?No
>>>>> +attempt is made at validating the combination of flags (other than the
>>>>> +usual validation done by option processing). ?This is implemented in
>>>>> +@file{lto/lto.c}:@code{lto_read_all_file_options}.
>>>>
>>>> This can be a big limiting factor for the wide adoption of LTO. In
>>>> LIPO, incompatible options are detected and modules not safe to
>>>> include are banned.
>>
>> If you have one file compiled with -fstrict-aliasing and one with
>> -fno-strict-aliasing - which one is "banned"? ?One idea of solving
>> the problem with LTO was to do paritioning according to the set
>> of command-line options.
>
> For correctness, it should take the most conservative one, for
> performance, ?it is the other way. For LIPO, the rule is simple -- the
> aux module option has to be compatible with the primary module's
> option -- in other words, the primary module's option will take
> precedence (i.e., used for aux modules in its group) regardless,
> however if such option setting may make the aux module mis-compile,
> the aux module is excluded. ?Currently, only mechanical comparison is
> done, but it should allow the following: aux module with
> -fstrict-aliasing should be allowed to be included in the group with
> -fno-strict-aliasing as the primary option -- but there is a slight
> chance it may actually hurt performance.
So, do you have an extensive list of options and which one, the -f or
the -fno variant takes precedence? I was thinking of simply having
a white list of compatible options and treat everything else as
incompatible (and error) for LTO.
Richard.
> thanks,
>
> David
>
>
>>
>>> It's another bug in a long stream of bugs. ?We have discussed ways to
>>> address it (http://gcc.gnu.org/wiki/whopr), but so far it has not percolated
>>> to the top of anyone's todo list.
>>
>> And the paragraph is not true anyway. ?We only save and combine
>> (read: apply in random order) all target specific flags and a selected
>> set of generic flags. ?In general we use the optimization option set
>> provided at link time (which would be a more correct description
>> of what happens).
>>
>> Richard.
>>
>>>
>>> Diego.
>>>
>>
>