PR target/17101: question about powerpc s<cond> expanders

[David Edelsohn]

>>>>> Nathan Sidwell writes:

Nathan> PR 17101 is a problem with boolean operations.  rs6000.md contains
Nathan> seq, sne, sgt ... expanders, but the signed ones are explicitly
Nathan> disabled for non-POWER (i.e. POWERPC) targets. for instance

Nathan> why is that?  The unsigned variants are not so encumbered.

	There are short, straight-line PowerPC code sequences for
unsigned, but not for signed.  The signed sequences use the POWER "doz"
instruction that was removed from PowerPC.

Nathan> Also, the signed variants cut out comparisons with zero -- why
Nathan> do the unsigned ones not do so? Oversight?  In addition, some of
Nathan> the special cases seem ineffective at best, pessimizing at worst.
Nathan> Examining each in detail I find the following assembler for 'V OP 0'

	The GCC generic straight-line comparison with 0 sequences are as
good as the custom sequences.

Nathan> .seq: // baseline of 3 insns using the condition regs
Nathan> cmpwi 7,3,0
Nathan> mfcr 3
Nathan> rlwinm 3,3,31,1

Nathan> .sne: // hm, four insns emitted
Nathan> srawi 0,3,31
Nathan> xor 3,0,3
Nathan> subf 3,3,0
Nathan> srwi 3,3,31

Nathan> .sge: // 2 insns, this is better.
Nathan> nor 3,3,3
Nathan> srwi 3,3,31

Nathan> .sgt: // 3 insns, no better
Nathan> srawi 0,3,31
Nathan> subf 0,3,0
Nathan> srwi 0,0,31

Nathan> .sle: // 3 insns, no better
Nathan> addi 0,3,-1
Nathan> or 0,0,3
Nathan> srwi 0,0,31

Nathan> .slt: // 1 insn, yay!
Nathan> srwi 3,3,31

Nathan> comments?

	The number of instructions do not correspond to the cost.
Compares, moving bits from condition registers, and bit extraction is
slower on newer PowerPC processors.

David