This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PR lto/41528] Add internal documentation in doc/lto.texi


Currently as I mentioned, only very mechanical comparison is done --
it simply removes all -Wxxx options (and some others I forgot) and
compare the option list.

David

On Mon, Nov 15, 2010 at 2:24 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> 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.
>>>>
>>>
>>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]