[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from amker at gcc dot gnu.org --- Fixed
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #19 from amker at gcc dot gnu.org --- I think this is fixed now.
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #18 from ctice at gcc dot gnu.org --- Author: ctice Date: Fri Apr 8 17:09:09 2016 New Revision: 234832 URL: https://gcc.gnu.org/viewcvs?rev=234832&root=gcc&view=rev Log: Unify changes with Android's GCC 4.9 compiler. Add the following changes from the Android GCC 4.9 compiler (mostly adding fixes for aarch64): Fix mingw build breakage 1) Add missing _GCOV_fopen if !__KERNEL__ 2) Use _fullpath Backport Cortex-A57's machine description support from trunk Adjust generic move costs for aarch64. Backport from trunk Enable C++ exceptions and RTTI by default. Modify LINK_SPEC to pass --fix-cortex-a53-843419 as default Rename libstdc++.so to libgnustl_shared.so when enabling bionic libs. Drop mips64r2 from Android compiler's multilib Merge "Drop mips64r2 from Android compiler's multilib" Adjust several costs for AArch64: Refactor aarch64_address_costs; add cost tables for Cortex-A7; better estimate cost of building a constant; wrap aarch64_rtx_costs to dump verbose output; factor out common MULT cases; det default costs and handle vector modes; cost memory accesses using address costs; better cost logical operations; improve costs for div/mod and sign/zero extend operations; cost comparisons, flag setting operators and IF_THEN_ELSE; cost more Floating point RTX; cost TRUNCATE, SET, SYMBOL_REF, HIGH and LO_SUM; dump a message if we are unable to cost an insn; fix typos in cost data structure. Add several improvements for AArch64 (Backported from GCC 5): (spill code - swap order in shr patterns; spill code - swap order in shl pattern; fix aarch64_rtx_costs of PLUS/MINUS; cost operand 0 in FP compare-with-0.0 case; properly cost FABD pattern; properly handle mvn-register and add EON+shift pattern and cost appropriately). Disable inlining of memcpy for x86 with 'rep movs'. Default to TLS guard for x86 stack-protector. Change gcc BASE-VER from 4.9.x-google to 4.9.x Cherry pick the following fixes from trunk: PR bootstrap/66638, 67954 (svn rev 230894, PR tree-optimization/65447, PR tree-optimization/52563, tree-optimization/62173, PR tree-optimization/48052, PR 64878, PR65048, PR65177, PR65735. Port revision 219584 from linaro/gcc-4_9-branch Fix for arm64 bad code for copysignl. Added: branches/google/gcc-4_9-mobile/gcc/sancov.c branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/ branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/asan.c branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic0.c branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic1.c branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic2.c Modified: branches/google/gcc-4_9-mobile/ChangeLog branches/google/gcc-4_9-mobile/config/futex.m4 branches/google/gcc-4_9-mobile/configure branches/google/gcc-4_9-mobile/configure.ac branches/google/gcc-4_9-mobile/gcc/BASE-VER branches/google/gcc-4_9-mobile/gcc/ChangeLog branches/google/gcc-4_9-mobile/gcc/Makefile.in branches/google/gcc-4_9-mobile/gcc/builtins.def branches/google/gcc-4_9-mobile/gcc/cfghooks.c branches/google/gcc-4_9-mobile/gcc/cfgloop.c branches/google/gcc-4_9-mobile/gcc/cfgloop.h branches/google/gcc-4_9-mobile/gcc/common.opt branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-cores.def branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-elf-raw.h branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-linux.h branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-protos.h branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-tune.md branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.c branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.md branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.opt branches/google/gcc-4_9-mobile/gcc/config/i386/i386.c branches/google/gcc-4_9-mobile/gcc/config/linux-android.h branches/google/gcc-4_9-mobile/gcc/config/mips/t-linux-android64 branches/google/gcc-4_9-mobile/gcc/configure branches/google/gcc-4_9-mobile/gcc/doc/invoke.texi branches/google/gcc-4_9-mobile/gcc/except.c branches/google/gcc-4_9-mobile/gcc/expmed.c branches/google/gcc-4_9-mobile/gcc/gcov-io.h branches/google/gcc-4_9-mobile/gcc/loop-init.c branches/google/gcc-4_9-mobile/gcc/lra-constraints.c branches/google/gcc-4_9-mobile/gcc/omp-low.c branches/google/gcc-4_9-mobile/gcc/params.def branches/google/gcc-4_9-mobile/gcc/passes.def branches/google/gcc-4_9-mobile/gcc/sanitizer.def branches/google/gcc-4_9-mobile/gcc/testsuite/ChangeLog branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c branches/google/gcc-4_9-mobile/gcc/tree-cfg.c branches/google/gcc-4_9-mobile/gcc/tree-cfg.h branches/google/gcc-4_9-mobile/gcc/tree-chrec.c branches/goo
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
--- Comment #17 from amker at gcc dot gnu.org ---
(In reply to Stupachenko Evgeny from comment #15)
> The commit caused regressions on some benchmarks. Test to reproduce:
> (compilations flags: -Ofast)
>
> int foo (int flag, char *a)
>
> {
>
> short i, j;
>
> short l = 0;
>
> if (flag == 1)
>
> l = 3;
>
>
> for (i = 0; i < 4; i++)
>
> {
>
> for (j = l - 1; j > 0; j--)
>
> a[j] = a[j - 1];
>
> a[0] = i;
>
> }
>
> }
>
> Here value of l is between 0 and 3, and therefore value of the innermost
> loop bound (l - 1) is between -1 and 2.
>
> After the commit the innermost loop is replaced with memmove call. This is
> obviously not optimal as amount of memory to move is not greater than 2.
(In reply to amker from comment #16)
> (In reply to Stupachenko Evgeny from comment #15)
> > The commit caused regressions on some benchmarks. Test to reproduce:
> > (compilations flags: -Ofast)
> >
> > int foo (int flag, char *a)
> >
> > {
> >
> > short i, j;
> >
> > short l = 0;
> >
> > if (flag == 1)
> >
> > l = 3;
> >
> >
> > for (i = 0; i < 4; i++)
> >
> > {
> >
> > for (j = l - 1; j > 0; j--)
> >
> > a[j] = a[j - 1];
> >
> > a[0] = i;
> >
> > }
> >
> > }
> >
> > Here value of l is between 0 and 3, and therefore value of the innermost
> > loop bound (l - 1) is between -1 and 2.
> >
> > After the commit the innermost loop is replaced with memmove call. This is
> > obviously not optimal as amount of memory to move is not greater than 2.
>
> Hi, thank you for reporting this. I shall have a look.
This is latent optimization issue in loop-niter/loop-dist revealed because more
scev are recognized now.
I filed PR66646 for tracking.
Thanks,
bin
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #16 from amker at gcc dot gnu.org ---
(In reply to Stupachenko Evgeny from comment #15)
> The commit caused regressions on some benchmarks. Test to reproduce:
> (compilations flags: -Ofast)
>
> int foo (int flag, char *a)
>
> {
>
> short i, j;
>
> short l = 0;
>
> if (flag == 1)
>
> l = 3;
>
>
> for (i = 0; i < 4; i++)
>
> {
>
> for (j = l - 1; j > 0; j--)
>
> a[j] = a[j - 1];
>
> a[0] = i;
>
> }
>
> }
>
> Here value of l is between 0 and 3, and therefore value of the innermost
> loop bound (l - 1) is between -1 and 2.
>
> After the commit the innermost loop is replaced with memmove call. This is
> obviously not optimal as amount of memory to move is not greater than 2.
Hi, thank you for reporting this. I shall have a look.
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
Stupachenko Evgeny changed:
What|Removed |Added
CC||evstupac at gmail dot com
--- Comment #15 from Stupachenko Evgeny ---
The commit caused regressions on some benchmarks. Test to reproduce:
(compilations flags: -Ofast)
int foo (int flag, char *a)
{
short i, j;
short l = 0;
if (flag == 1)
l = 3;
for (i = 0; i < 4; i++)
{
for (j = l - 1; j > 0; j--)
a[j] = a[j - 1];
a[0] = i;
}
}
Here value of l is between 0 and 3, and therefore value of the innermost loop
bound (l - 1) is between -1 and 2.
After the commit the innermost loop is replaced with memmove call. This is
obviously not optimal as amount of memory to move is not greater than 2.
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 Bug 48052 depends on bug 66396, which changed state. Bug 66396 Summary: [6 regression] FAIL: gcc.dg/graphite/run-id-pr47593.c execution test https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66396 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #14 from amker at gcc dot gnu.org --- Author: amker Date: Tue Jun 2 10:19:18 2015 New Revision: 224020 URL: https://gcc.gnu.org/viewcvs?rev=224020&root=gcc&view=rev Log: PR tree-optimization/48052 * cfgloop.h (struct control_iv): New. (struct loop): New field control_ivs. * tree-ssa-loop-niter.c : Include "stor-layout.h". (number_of_iterations_lt): Set no_overflow information. (number_of_iterations_exit): Init control iv in niter struct. (record_control_iv): New. (estimate_numbers_of_iterations_loop): Call record_control_iv. (loop_exits_before_overflow): New. Interface factored out of scev_probably_wraps_p. (scev_probably_wraps_p): Factor loop niter related code into loop_exits_before_overflow. (free_numbers_of_iterations_estimates_loop): Free control ivs. * tree-ssa-loop-niter.h (free_loop_control_ivs): New. gcc/testsuite/ChangeLog PR tree-optimization/48052 * gcc.dg/tree-ssa/scev-8.c: New. * gcc.dg/tree-ssa/scev-9.c: New. * gcc.dg/tree-ssa/scev-10.c: New. * gcc.dg/vect/pr48052.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-10.c trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-8.c trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-9.c trunk/gcc/testsuite/gcc.dg/vect/pr48052.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloop.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree-ssa-loop-niter.h
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #13 from AK --- We have an updated patch that works for both the cases. https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01991.html
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #12 from zaafrani --- Thank you for the feedback. We excluded start value that is constant because it is already working. To our knowledge, only when the start value is unknown and the loop index type is of unsigned type that we fail to recognize non-overflow for situations when it is possible to deduce so. For most other cases, current analysis done in scev_probably_wraps_p seems to be working fine. We also added the assumption of step equal 1 so that we can make correct decision about non-overflow. So, basically we’d rather catch few simple cases and make them work then try to generalize the scope and not being to prove much. On Wed, May 6, 2015 at 1:56 AM, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 > > --- Comment #11 from Richard Biener --- > That's an interesting idea - your argument is that if niter analysis was able > to compute an expression for the number of iterations and the cast we are > looking at > is a widening of a BIV then it is ok to assume the BIV does not wrap. > > Unfortunately this breaks down (eventually not in practice due to your > exclusion of constant initial BIV value) for cases like > > > for (unsigned i = 3; i != 2; i+=7) > ; > > where niter analysis can still compute the number of iterations (I've made > the numbers up, so maybe that loop will never terminate...). > > Still the idea is interesting as we might be able to record whether BIVs > overflow or not. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #11 from Richard Biener --- That's an interesting idea - your argument is that if niter analysis was able to compute an expression for the number of iterations and the cast we are looking at is a widening of a BIV then it is ok to assume the BIV does not wrap. Unfortunately this breaks down (eventually not in practice due to your exclusion of constant initial BIV value) for cases like for (unsigned i = 3; i != 2; i+=7) ; where niter analysis can still compute the number of iterations (I've made the numbers up, so maybe that loop will never terminate...). Still the idea is interesting as we might be able to record whether BIVs overflow or not.
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
zaafrani changed:
What|Removed |Added
CC||az.zaafrani at gmail dot com
--- Comment #10 from zaafrani ---
Created attachment 35459
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35459&action=edit
patch
This is an old thread and we are still running into similar issues: Code is not
being vectorized on 64-bit target due to scev not being able to optimally
analyze overflow condition.
While the original test case shown here seems to work now, it does not work if
the start value is not a constant and the loop index variable is of unsigned
type: Ex
void loop2( double const * __restrict__ x_in, double * __restrict__ x_out,
double const * __restrict__ c, unsigned int N, unsigned int start) {
for(unsigned int i=start; i!=N; ++i)
x_out[i] = c[i]*x_in[i];
}
Here is our unit test:
int foo(int* A, int* B, unsigned start, unsigned B)
{
int s;
for (unsigned k = start; k
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
--- Comment #9 from vincenzo Innocente
2011-03-14 10:08:29 UTC ---
It is interesting to note that in case of fixed size (such as in these trivial
or template examples)
vectorization works also for unsigned int
void loop10( double const * __restrict__ x_in, double * __restrict__ x_out,
double const * __restrict__ c) {
for(unsigned int i=0; i!=10; ++i)
x_out[i] = c[i]*x_in[i];
}
template
void loopTu( T const * __restrict__ x_in, T * __restrict__ x_out, T const *
__restrict__ c) {
for(unsigned int i=0; i!=N; ++i)
x_out[i] = c[i]*x_in[i];
}
template
void loopTull( T const * __restrict__ x_in, T * __restrict__ x_out, T const *
__restrict__ c) {
for(unsigned long long i=0; i!=N; ++i)
x_out[i] = c[i]*x_in[i];
}
void go(double const * __restrict__ x_in, double * __restrict__ x_out, double
const * __restrict__ c) {
loopTu(x_in, x_out, c);
loopTull(x_in, x_out, c);
}
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #8 from rguenther at suse dot de 2011-03-11 10:26:47 UTC --- On Fri, 11 Mar 2011, vincenzo.innocente at cern dot ch wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 > > --- Comment #7 from vincenzo Innocente > 2011-03-11 10:16:37 UTC --- > what's the probablity to have this fixed? A fix for this is quite involved (and honestly its on my TODO list for at least two years - but I chickened out repeatedly because of all the issues). I'm not sure if a SCEV local fix is possible, Sebastian will probably comment on this. Richard.
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #7 from vincenzo Innocente 2011-03-11 10:16:37 UTC --- what's the probablity to have this fixed? We depend on a third party matrix library that is fully templated and uses everywhere "unsigned int" I made a test with a sed -i 's/unsigned int/unsigned long long/g' and it MAKES a difference (up to a factor 2 in speed). This modification (although trivial) changes the type of templated vector and matrix, the signature of functions and also affects user code. It is neither transparent nor backward compatible. I think we cannot afford the change in production: much easier to change compiler version! Thanks for any effort dedicated to solve this issue, Vincenzo On 10 Mar, 2011, at 12:22 PM, paolo.carlini at oracle dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 > > Paolo Carlini changed: > > What|Removed |Added > > CC||paolo.carlini at oracle dot > ||com > > --- Comment #5 from Paolo Carlini > 2011-03-10 11:22:26 UTC --- > Vincenzo, if I understand correctly, maybe Sebastian can also tell us more, > the > issue seems that, at some stage, the logic is fully general only assuming the > widest unsigned type (*), doesn't cope with smaller types. Thus, if my theory > is correct, unsigned char, unsigned short, etc, all should cause problems. On > the other hand, on x86_64, unsigned long, unsigned long long, size_t, are all > the same size, and all work (**) > > (*) I don't consider int128, I don't think is relevant for loop optimization. > (**) On x86, however, unsigned int (aka unsigned long) appears to work, hum. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug. -- Il est bon de suivre sa pente, pourvu que ce soit en montant. A.G. http://www.flickr.com/photos/vin60/1320965757/
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #6 from Paolo Carlini 2011-03-10 11:30:58 UTC --- Well, on x86, in terms of addressing unsigned int (aka long) *is* the widest type, morally unsigned long long doesn't count.
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #5 from Paolo Carlini 2011-03-10 11:22:26 UTC --- Vincenzo, if I understand correctly, maybe Sebastian can also tell us more, the issue seems that, at some stage, the logic is fully general only assuming the widest unsigned type (*), doesn't cope with smaller types. Thus, if my theory is correct, unsigned char, unsigned short, etc, all should cause problems. On the other hand, on x86_64, unsigned long, unsigned long long, size_t, are all the same size, and all work (**) (*) I don't consider int128, I don't think is relevant for loop optimization. (**) On x86, however, unsigned int (aka unsigned long) appears to work, hum.
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #4 from vincenzo Innocente 2011-03-10 10:54:07 UTC --- Thanks for the fast reation. I would like to point out that, at least on x86_64, the only one that does not work is "unsigned int" "unsigned long long (aka size_t)" seems to work (see 3,4 and 5th loop in my example) vincenzo On 10 Mar, 2011, at 11:23 AM, paolo.carlini at oracle dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 > > --- Comment #3 from Paolo Carlini > 2011-03-10 10:22:48 UTC --- > Thanks for the analysis. I knew about the difference between signed and > unsigned, makes sense. Not knowing in detail the internals of the optimization > the puzzling bit is that types wider than unsigned int already work fine. The > problem seems fixable, somehow ;) > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug. -- Il est bon de suivre sa pente, pourvu que ce soit en montant. A.G. http://www.flickr.com/photos/vin60/1320965757/
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #3 from Paolo Carlini 2011-03-10 10:22:48 UTC --- Thanks for the analysis. I knew about the difference between signed and unsigned, makes sense. Not knowing in detail the internals of the optimization the puzzling bit is that types wider than unsigned int already work fine. The problem seems fixable, somehow ;)
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.03.10 09:46:16
CC||spop at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther 2011-03-10
09:46:17 UTC ---
This is a known issue with POINTER_PLUS_EXPR semantics, how the C frontend
handles pointer-based array accesses and fold. And in the end SCEV analysis.
The issue is we end up with
*(c + (((long unsigned int)i) * 8))
with that 'long unsigned int' being sizetype. At the point of SCEV
analysis we do not factor in the fact that i does not wrap around and
that because of this the evolution is
{ c, +, 8 }
With signed integers we simply exploit undefined behavior.
So yes, it's a known problem (but I always fail to remember a testcase
where it matters ;)).
In the very end my plan was to fix this all with no-undefined-overflow
branch, but maybe Sebastian can think of a way to use number-of-iteration
analysis in SCEV? (Ugh, that's a chicken-and-egg problem, no?)
[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 Paolo Carlini changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2011-03-10 00:21:19 UTC --- Richard, is this issue known? Seems indeed rather weird to me.
