This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Extend memset recognition
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 19 Aug 2012 11:55:38 -0700
- Subject: Re: [PATCH][RFC] Extend memset recognition
- References: <Pine.LNX.4.64.1205301315140.5860@jbgna.fhfr.qr> <Pine.LNX.4.64.1205311251460.5860@jbgna.fhfr.qr> <Pine.LNX.4.64.1206051120030.29541@jbgna.fhfr.qr>
On Tue, Jun 5, 2012 at 2:21 AM, Richard Guenther <rguenther@suse.de> wrote:
> On Thu, 31 May 2012, Richard Guenther wrote:
>
>> On Wed, 30 May 2012, Richard Guenther wrote:
>>
>> >
>> > The patch below extents memset recognition to cover a few more
>> > non-byte-size store loops and all byte-size store loops. This exposes
>> > issues with our builtins.exp testsuite which has custom memset
>> > routines like
>> >
>> > void *
>> > my_memset (void *d, int c, size_t n)
>> > {
>> > char *dst = (char *) d;
>> > while (n--)
>> > *dst++ = c;
>> > return (char *) d;
>> > }
>> >
>> > Now, for LTO we have papered over similar issues by attaching
>> > the used attribute to the functions. But the general question is - when
>> > can we be sure the function we are dealing with are not the actual
>> > implementation for the builtin call we want to generate? A few
>> > things come to my mind:
>> >
>> > 1) the function already calls the function we want to generate (well,
>> > it might be a tail-recursive memset implementation ...)
>> >
>> > 2) the function availability is AVAIL_LOCAL
>> >
>> > 3) ... ?
>> >
>> > For sure 2) would work, but it would severely restrict the transform
>> > (do we care?).
>> >
>> > We have a similar issue with sin/cos -> sincos transform and a
>> > trivial sincos implementation.
>> >
>> > Any ideas?
>> >
>> > Bootstrapped (with memset recognition enabled by default) and tested
>> > on x86_64-unknown-linux-gnu with the aforementioned issues.
>>
>> The following fixes it by simply always adding
>> -fno-tree-loop-distribute-patterns to builtins.exp.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>>
>> If there are no further comments I'll go with the local advise from
>> Micha who says "who cares".
>
> Now done with the much simpler patch below (after all the loop
> distribution TLC).
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2012-06-05 Richard Guenther <rguenther@suse.de>
>
> PR tree-optimization/53081
> * tree-loop-distribution.c (generate_memset_builtin): Handle all
> kinds of byte-sized stores.
> (classify_partition): Likewise.
> (tree_loop_distribution): Adjust seed statements used for
> !flag_tree_loop_distribution.
>
> * gcc.dg/tree-ssa/ldist-19.c: New testcase.
> * gcc.c-torture/execute/builtins/builtins.exp: Always pass
> -fno-tree-loop-distribute-patterns.
>
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321
--
H.J.