Re: RFC: Strategy for cc0 -> CCmode conversion for the AVR target.

[Paolo Bonzini <bonzini at gnu dot org>]

> The condition-code re-use issue is the point, where, IMO, the link to the 
> subreg-lowering 2.) shows up. After, e.g., breaking down a HI mode "sub" 
> operation into two QI mode "sub" and "sub-with-carry"s at expand, I consider 
> it to be extremely difficult to make the mid-end smart enough to identify 
> that a the end of the QI "sub-with-carry" the condition code is set according 
> to the corresponding HImode substract operation.

As a last resort, ou can always use peephole2's to remove unnecessary 
subtracts on the HImode values.

> (parallel [
>  (use (operands[0]))
>  (set (operands[0]) (minus:HI (operands[1]) (operands[2]))
>  (note "please delete the entire embracing parallel instruction before 
> register life-time analysis by a new pass: It pretends to use operands 1 and 
> 2 while in fact this instruction does nothing except from giving hints to 
> GCSE.")
> ])

This seems define_insn_and_split, but it is a lot more complex than what 
you probably can do...

IIRC, s390 does use add with carry and subtract with borrow instructions 
effectively (alc and slb in IBM360^W s390-ese).  Search the archives on 
google or gmane.

> - combine -re-run

No way, combine is too expensive...  Its simplification engine is fine, 
but a lot of things ought to be redone from scratch so that it becomes a 
serious instruction selection pass.

Paolo