Expanding instructions with condition codes inter-deps

[Paulo J. Matos]

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