> From: Denis Chertykov <[EMAIL PROTECTED]> >> - 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.
Thanks for your patience, and now that I understand GCC's spill/reload requirements/limitations a little better; I understand your desire to merge compare-and-branch. However, as an alternative to merging compare-and-branch's to overcome the fact that the use of a conventional add operation to calculate the effective spill/reload address for FP offsets >63 bytes would corrupt the machine's cc-state that a following conditional skip/branch may be dependant on; I wonder if it may be worth considering simply saving the status register to a temp register and restoring it after computing the spill/reload address when a large FP offset is required. (which seems infrequent relative to those with <63 byte offsets, so would typically not seem to be required?) If this were done, then not only could compares be split from branches, and all side-effects fully disclosed; but all compares against 0 resulting from any arbitrary expression calculation may be initially directly optimized without relying on a subsequent peephole optimization to accomplish. Further, if there were a convenient way to determine if the now fully exposed cc-status register was "dead" (i.e. having no dependants), then it should be then possible to eliminate its preservation when calculating large FP offset spill/reload effective addresses, as it would be known that no subsequent conditional skip/branch operations were dependant on it. With this same strategy, it may even be desirable to then conditionally preserve the cc-status register abound all corrupting effective address calculations when cc-status register is not "dead", as it would seem to be potentially more efficient to do so rather than otherwise needing to re-compute an explicit comparison afterward? (Observing that I'm basically suggesting treating the cc-status register like any other hard register, who's value would need to be saved/restored around any corrupting operation if it's value has live dependants; what's preventing GCC's register and value dependency tracking logic from being able to manage its value properly just like it can for other register allocated values ?)
