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

[Abe]

[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