This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR56888
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Jakub Jelinek <jakub at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 14 Feb 2017 09:33:03 +0100
- Subject: Re: [PATCH] Fix PR56888
- Authentication-results: sourceware.org; auth=none
- References: <alpine.LSU.2.11.1602221342040.31547@t29.fhfr.qr> <20160222125418.GI3017@tucnak.redhat.com> <alpine.LSU.2.11.1602221356490.31547@t29.fhfr.qr> <alpine.LSU.2.11.1602221401430.31547@t29.fhfr.qr> <20160223102809.GC43696@kam.mff.cuni.cz> <alpine.LSU.2.11.1602231230191.31547@t29.fhfr.qr>
On Tue, Feb 23, 2016 at 12:32 PM, Richard Biener <rguenther@suse.de> wrote:
> On Tue, 23 Feb 2016, Jan Hubicka wrote:
>
>> >
>> > Ok, so maybe a better question to symtab would be if there is an
>> > actual definition for what __builtin_FOO will call. Not really
>> > whether that definition is cfun. Of course all the fortify
>> > always-inline wrappers should not count as such (just in case
>> > the symtab code is confused about those).
>>
>> Also GNU extern inlines that are often used to deal special cases.
>> >
>> > So,
>> >
>> > bool symbol_table::have_definition (enum built_in_fn);
>> >
>> > ? Not sure how to best implement that either. asmname lookups are
>> > expensive ...
>>
>> I am back from China trip, so i can handle you patch if you want.
Honza - ping. Can you please think of a symtab predicate that tells me
whether a cgraph node is an implementation for BUILT_IN_X? (see original
patch in this thread).
It's before another GCC release and we're trying to improve QOI wise for
almost 3 releases now...
Thanks a lot,
Richard.
>> I see that by stopping the optimization on whole translation unit that
>> defines memcpy/memset will solve the reachability issue I mentioned
>> in previous mail, but also when LTOing stuff like Linux kernel, it will
>> prevent the optimization on the whole program.
>
> Yes, but I think it's reasonable to disable such transform if the
> memcpy implementation is being optimized.
>
>> I am not quite sure how to deal with the alwaysinline wrappers however,
>> because there theoretically may contain memcpy/memset loops themselves.
>
> It might be a non-issue as we are doing the transforms only after
> inlining when those bodies should be gone and thus symtab shouldn't see
> such implementation.
>
> Better to double-check, of course. We'd want
>
> #include <string.h>
>
> int main()
> {
> int s[1204];
> for (int i = 0; i < 1204; ++i)
> s[i] = 0;
> memset (s, 0, sizeof (s));
> }
>
> still be optimized as memset.
>
> Richard.
>
>> Honza
>> >
>> > Richard.
>>
>>
>
> --
> Richard Biener <rguenther@suse.de>
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)