This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Loop distribution improvements
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Richard Biener <richard dot guenther at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 5 Apr 2013 10:12:36 +0200 (CEST)
- 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>
- Reply-to: gcc-patches at gcc dot gnu dot org
On Fri, 5 Apr 2013, Jakub Jelinek wrote:
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?
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.
Shouldn't we change integer_all_onesp to do what its name says and create
a separate integer_minus_onep for the single place I could find where it
would break, the folding of x * -1 ?