AVR: CC0 to CCmode conversion

[Denis Chertykov]

Paul Schlie <schlie@comcast.net> writes:


[...]

> 
> > I think that better to support
> > cmpHI, cbranch  ->  cmpQI1_set_CC, cmpQI2_use_CC, cbranch. because
> > AVR is a microcontroller and code size more important than code speed.
> 
> - I fully agree that code-size tends to be most important, which is why I
>   believe it's important to enable instruction scheduling/re-ordering
>   optimizations that are capable of eliminating potentially unnecessary
>   explicit comparison operations for wider than byte-sized operand results
>   against 0, if the instructions within a basic block can be safely
>   rescheduled to eliminate them.
> 
>   Which would seem to require that both instruction FLAGS_REG side-effects
>   be fully exposed, and correspondingly that conditional branches expose
>   their dependency on them (and all are visible during DFCG scheduling).
> 
> - possibly something like: ?
> 
>   (define_insn "*addhi3"
>     [(set (match_operand:HI 0 ...)
>        (plus:HI (match_operand:HI 1 ...)
>                 (match_operand:HI 2 ...)))
>      (set (reg ZCMP_FLAGS)
>        (compare:HI (plus:HI (match_dup 1) (match_dup 2))) (const_int 0))
>      (set (reg CARRY_FLAGS)
>        (compare:HI (plus:HI (match_dup 1) (match_dup 2))) (const_int 0))]
>     ""
>     "@ add %A0,%A2\;adc %B0,%B2
>        ..."
>     [(set_attr "length" "2, ...")])

You have presented a very good example. Are you know any port which
already used this technique ?
As I remember - addhi3 is a special insn which used by reload.
The reload will generate addhi3 and reload will have a problem with
two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad
surprise for reload. :( As I remember.

Denis.