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
