[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
