This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Expanding instructions with condition codes inter-deps
On 19/10/11 00:10, Richard Henderson wrote:
The thing that's almost certainly missing is that the NAND pattern
must SET your flags register, not simply clobber it. Otherwise the
dependency between the ADDC and the NAND will never be created properly.
I understand that there's a missing SET of RCC in the NAND. However,
what's the set source, we are really not sure what we are setting RCC to.
Also, I am following the pattern set by rx and mn10300 of using a pseudo
register for the flags. So my nadd pattern is:
(define_insn "negqi2"
[(set (match_operand:QI 0 "register_operand" "=c")
(neg:QI (match_operand:QI 1 "register_operand" "0")))
(clobber (reg:CC RCC))]
""
{
operands[2] = const0_rtx;
return "nadd\\t%0,%2";
})
(define_insn "*negqi2_flags"
[(set (match_operand:QI 0 "register_operand" "=c")
(neg:QI (match_operand:QI 1 "register_operand" "0")))
(set (reg RCC)
(compare (neg:QI (match_dup 1))
(const_int 0)))]
"reload_completed && xap_match_ccmode(insn, CCmode)"
{
operands[2] = const0_rtx;
return "nadd\\t%0,%2";
})
It doesn't make sense to me, to add a
(set (reg:C RCC) (neg:QI (match_dup 1)))
into the parallel since this is going to class with the already existing
_flags version of negqi which sets RCC.
(for example, it would be ok to output negqi2, xorqi3 and
addc_internal since xorqi3 only sets N and Z, not the Carry bit)
For that you'd have to model all of the flags bits independently.
I don't believe any target has found that level of complexity to
be worth the trouble.
So, almost certainly, you don't.
Well, if I am only interested in th Carry flag, I can as well just
bother about that. It wouldn't be much of a trouble since I already have
the mode CC_Cmode to model instruction which only set this flag.
--
PMatos