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

[Alan Lawrence]

Abe wrote:

> Ideally, I/we fix the above problem -- and the rest of the regressions in the new if converter --

Ok, what are these regressions? You say you've tested on x86_64 and only 
ifcvt-18.c fails (hence your xfail), so how does one find them?

> In particular, I remember that "result = condition ? array1[index] : array2[maybe the same index, maybe not]"
> is being converted too early IMO.  IOW, somewhere in GCC an array dereference is being considered
> as either impure, too-expensive, or both.  "array[index]" in C [not in C++!: operator overloading]
> AFAIK is always pure and is always low-cost whenever the index expression is pure and low-cost.

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

--Alan