Paul Schlie <[EMAIL PROTECTED]> 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.
