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

[Alan Lawrence]

Abe wrote:
[snip]
> Predication of instructions can help to remove the burden of the conditional branch, but is not available on all relevant architectures.
> In some architectures that are typically implemented in modern high-speed processors -- i.e. with high core frequency, caches, speculative execution, etc. --
> there is not full support for predication [as there is, for example, in 32-bit ARM] but there _is_ support for "conditional move" [hereinafter "cmove"].
> If/when the ISA in question supports cmove to/from main memory, perhaps it would be profitable to use two cmoves back-to-back with opposite conditions
> and the same register [destination for load, source for store] to implement e.g. "temp = c ? X[x] : Y[y]" and/or "temp = C[c] ? X[x] : Y[y]" etc.
> Even without cmove to/from main memory, two cmoves back-to-back with opposite conditions could still be used, e.g. [not for a real-world ISA]:
>    load X[x] -> reg1
>    load Y[y] -> reg2
>    cmove   c  ? reg1 -> reg3
>    cmove (!c) ? reg2 -> reg3
> 
> Or even better if the ISA can support something like:
>    load X[x] -> reg1
>    load Y[y] -> reg2
>    cmove (c ? reg1 : reg2) -> reg3
> 
> However, this is a code-gen issue from my POV, and at the present time all the if-conversion work is occurring at the GIMPLE level.
> If anybody reading this knows how I could make the if converter generate GIMPLE that leads to code-gen that is better for at
> least one ISA

Ramana writes that your patch for PR46029 generates more 'csel's (i.e. the 
second form you write) for AArch64: 
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01721.html

of course this says nothing about whether there is *some* other ISA that gets 
regressed!

HTH
Alan