This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2] Fix multiple target clones nodes (PR lto/66295).
- From: Martin Liška <mliska at suse dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, evstupac at gmail dot com, Jan Hubicka <hubicka at ucw dot cz>
- Date: Tue, 14 Mar 2017 11:09:31 +0100
- Subject: Re: [PATCH 2] Fix multiple target clones nodes (PR lto/66295).
- Authentication-results: sourceware.org; auth=none
- References: <3fc1a062-956e-ae18-21ff-296685d4f8c8@suse.cz> <2663b3eb-d7ef-e5ca-6d6e-28f6b9f02fc5@suse.cz> <CAFiYyc31_g1GRaRL-NbFBwqpza6W23d0AK0zvxSda-G9Z7jK9A@mail.gmail.com>
On 03/14/2017 10:46 AM, Richard Biener wrote:
> On Mon, Mar 13, 2017 at 4:19 PM, Martin Liška <mliska@suse.cz> wrote:
>> Hello.
>>
>> This is a small follow-up patch, where local.local flag should be also dropped
>> for a default implementation.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>
> I see we have clered the flag on the clones this way. But isn't it
> bogus to have
> it set in the first place? That is, isn't analysis sofar given bogus info?
Yes, I did it for clones. Reason why we mark it is that local flag is set
by pass_ipa_function_and_variable_visibility pass, which runs before MV pass.
I can imagine MV can bail out for a non-trivial reason and the visibility pass
should somehow simulate and predict what happens in the MV pass?
Martin
>
> Shouldn't we instead fix local_p to not mark functions with MV attribute local
> in the first place?
>
> Richard.
>
>> Martin