ifcvt limitations?

[Kyrill Tkachov]

Hi all,

I'm looking at a case on aarch64 that's not if-converted to use conditional 
moves:


typedef unsigned char uint8_t;
typedef unsigned int uint16_t;

uint8_t foo(const uint8_t byte, const uint16_t generator)
{
  if (byte & 0x80) {
    return (byte << 1) ^ (generator & 0xff);
  } else {
    return byte << 1;
  }
}

For aarch64 we fail to if-convert and generate:
foo:
        uxtb    w2, w0
        lsl     w3, w2, 1
        uxtb    w0, w3
        tbnz    x2, 7, .L5
        ret
        .p2align 3
.L5:
        eor     w0, w3, w1
        uxtb    w0, w0
        ret


whereas on x86 we if convert successfully and use a conditional move/select:
        leal    (%rdi,%rdi), %eax
        xorl    %eax, %esi
        testb   %dil, %dil
        cmovs   %esi, %eax
        ret



After fixing some of the branch costs in aarch64 and a bogus cost calculation 
in cheap_bb_rtx_cost_p
I'm stuck on noce_process_if_block (in ifcvt.c) and what I think is a 
restriction that the THEN-block contents have to be only a single set insn. 
This fails on aarch64 because we get an extra zero_extend.

In particular, the following check in noce_process_if_block triggers:
  insn_a = first_active_insn (then_bb);
  if (! insn_a
      || insn_a != last_active_insn (then_bb, FALSE)
      || (set_a = single_set (insn_a)) == NULL_RTX)
    return FALSE;

Is there any particular reason why the code shouldn't be able to handle 
arbitrarily large contents
in then_bb (within a sane limit)?

Thanks,
Kyrill