This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: making the new if-converter not mangle IR that is already vectorizer-friendly


[Abe wrote:]
Ideally, I/we fix the above problem -- and the rest of the regressions in the new if converter --

[Alan wrote:]
OK, what are these regressions?

Each of these files` test cases currently fails to be autovectorized:

  gcc/testsuite/gcc.dg/vect/pr61194.c
  gcc/testsuite/gcc.dg/vect/vect-mask-load-1.c
  gcc/testsuite/gcc.dg/vect/vect-mask-loadstore-1.c
  gcc/testsuite/gcc.target/i386/avx2-gather-6.c
  gcc/testsuite/gcc.target/i386/avx2-vect-aggressive-1.c
  gcc/testsuite/gcc.target/i386/avx2-vect-aggressive.c


[Alan wrote:]
Well, any array access could introduce an extra fault (unless it's dominated by another equivalent (read/write) access)...?

I respectfully disagree.  Given code such as this:

  for (unsigned short index = 1; index < 9; ++index)
    array[index] = index;


... and assuming that "array" is an _array_ variable, i.e. it is _not_ a [re-assignable] pointer, it should be
clear IMO to all human readers that this code will not segfault, and if any compiler cannot also correctly arrive
at the conclusion "this array access is always good", then that compiler needs to get better at analysis IMO.

AFAIK, value range propagation [in the above example, for "index"] has been in GCC for many years...

  http://www.airs.com/dnovillo/Papers/gcc2005.pdf

  https://gcc.gnu.org/ml/gcc-patches/2000-07/msg00968.html

  http://gcc.1065356.n5.nabble.com/Value-range-propagation-pass-in-4-0-1-RC1-or-not-td660293.html

[and I`m sure there are many more]

Regards,

Abe


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]