"Petar Bajic" <petar.bajic@xxxxxxxxxxxxxxx> writes:
> > It's not generated, like it's not in the asm code. Instead, movsi_insn is
> > used and bad asm code is generated.
> >
> > for c code :
> > if (in1 == 0)
> > out = in2;
> > return out;
> >
> > I expect asm to look like this
> > lw r2,4(r30) ; in2
> > lw r16,(r30) ; in1
> > movz r1, r2, r16
> >
> > instead, code looks like this
> >
> > lw r2,4(r30)
> > lw r16,(r30)
> > movz r1,r2,r16
> > movn r1,r16,r16
> >
> > expand debug file is in attach, I don't see that movsicc_expand is used...
> > (although this is my first time to look at expand files)
> > movsicc_insn first appears in short.c.11.ce1
> >
> > can you see why pattern is not matched with expand?
Looking back at your earlier message, you had this:
(define_expand "movsicc"
[(set (match_operand:SI 0 "register_operand" "=d,d")
(if_then_else:SI (eq:SI (match_operand:SI 2 "register_operand" "=d,d") (const_int 0))
(match_operand:SI 1 "register_operand" "=d,d")
(match_dup 0)))]
The match_dup suggests that the first and last operands must be the
same, in which case "movz r1,r2,r16" is not permitted.
It may be correct for the pattern to not be matched with expand. It's
OK if the if-conversion pass picks it up, which seems to be what is
happening for you.
If the generated code you are getting is wrong, then problem is likely
in the define_insn patterns somewhere. They don't correct represent
what the instruction does, or they don't correctly implement it.
Ian
