This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Loop distribution improvements
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 5 Apr 2013 09:44:06 +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>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Apr 05, 2013 at 09:21:16AM +0200, Richard Biener wrote:
> Jakub Jelinek <email@example.com> 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 need
to rule out COMPLEX_CSTs (or do integer_all_onesp on each part instead).
And TYPE_PRECISION on VECTOR_CSTs won't be what we are looking for.