This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Loop distribution improvements
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 05 Apr 2013 12:46:48 +0200
- Subject: Re: [PATCH] Loop distribution improvements
- References: <20130404181758 dot GV4201 at tucnak dot redhat dot com> <258422fc-fbe2-4dda-b246-93f6d651219e at email dot android dot com> <20130404185713 dot GW4201 at tucnak dot redhat dot com> <a2208aa5-9468-4b5b-a891-2e84e3ed932e at email dot android dot com> <20130405074406 dot GZ4201 at tucnak dot redhat dot com>
Jakub Jelinek <email@example.com> wrote:
>On Fri, Apr 05, 2013 at 09:21:16AM +0200, Richard Biener wrote:
>> Jakub Jelinek <firstname.lastname@example.org> wrote:
>> >On Thu, Apr 04, 2013 at 08:37:47PM +0200, Richard Biener wrote:
>> >> Can you factor out a function that returns
>> >> A proper qimode value if possible or null and
>> >> Use it in both places?
>> >Like this?
>> You should be able to remove zero, minus one and constructor special
>> casing, no? Ok, maybe not constructor handling, but at least move
>No, because the function is only handling BITS_PER_UNIT == 8 &&
>CHAR_BIT == 8,
>plus is unnecessarily expensive for the common case of storing 0.
>But if you want, I can move all that integer_zerop / real_zerop /
>CONSTRUCTOR / integer_all_onesp handling into the function.
>BTW, the integer_all_onesp stuff is broken for this from what I can
>see, for complex
>numbers it returns true for -1 + 0i where all bytes aren't 0xff, so we
>to rule out COMPLEX_CSTs (or do integer_all_onesp on each part
>And TYPE_PRECISION on VECTOR_CSTs won't be what we are looking for.
Hmm, indeed. Or remove the -1 special casing altogether. Marc is probably right with his note as well.