This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
PR target/17101: question about powerpc s<cond> expanders
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: gcc <gcc at gcc dot gnu dot org>, David Edelsohn <dje at watson dot ibm dot com>, Geoffrey Keating <geoffk at apple dot com>
- Date: Fri, 12 Nov 2004 17:00:34 +0000
- Subject: PR target/17101: question about powerpc s<cond> expanders
- Organization: Codesourcery LLC
PR 17101 is a problem with boolean operations. rs6000.md contains
seq, sne, sgt ... expanders, but the signed ones are explicitly
disabled for non-POWER (i.e. POWERPC) targets. for instance
(define_expand "sgt"
[(clobber (match_operand:SI 0 "gpc_reg_operand" ""))]
""
"
{
if (! rs6000_compare_fp_p
&& (! TARGET_POWER || rs6000_compare_op1 == const0_rtx))
FAIL;
rs6000_emit_sCOND (GT, operands[0]);
DONE;
}")
why is that? The unsigned variants are not so encumbered.
Also, the signed variants cut out comparisons with zero -- why
do the unsigned ones not do so? Oversight? In addition, some of
the special cases seem ineffective at best, pessimizing at worst.
Examining each in detail I find the following assembler for 'V OP 0'
.seq: // baseline of 3 insns using the condition regs
cmpwi 7,3,0
mfcr 3
rlwinm 3,3,31,1
.sne: // hm, four insns emitted
srawi 0,3,31
xor 3,0,3
subf 3,3,0
srwi 3,3,31
.sge: // 2 insns, this is better.
nor 3,3,3
srwi 3,3,31
.sgt: // 3 insns, no better
srawi 0,3,31
subf 0,3,0
srwi 0,0,31
.sle: // 3 insns, no better
addi 0,3,-1
or 0,0,3
srwi 0,0,31
.slt: // 1 insn, yay!
srwi 3,3,31
comments?
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk