Paul Schlie <[EMAIL PROTECTED]> writes: > Is there any convenient way to reference the newly set register by an > instruction, as opposed to otherwise needing to redundantly re-specify > the operation producing it's value again? > > Thereby enabling something like: > > (insn xxx [(set (reg: A) (xxx: (reg: B) (reg: C))) > (set (reg: CC) (newly-set-reg: A)) > ....) > > (insn branch-equal (set (pc) (if_then_else > (ge: CC 0) > (label_ref 23) > (pc))) > ...) > > Thereby enabling an xxx instruction to specify the CC register value being > virtually assigned the result of the instruction's operation (i.e. no code > will actually be generated for assignments to the CC register), upon which > an independently specified conditional branch may be defined to be dependant > upon it (the virtual CC register). Which would seem to be a simple way to > closely approximate the semantics of a global cc-state register?
Yes, a backend could be implemented this way. There are two problems. 1) Many of the optimizers analyze instructions by first calling single_set and working with the results of that. For example, combine won't work with any insn for which single_set returns NULL. And single_set will normally return NULL for your insn xxx above. 2) Reload requires the ability to insert arbitrary instructions between any pair of instructions. The instructions inserted by reload will load registers from memory, store registers to memory, and possibly, depending on the port, move values between different classes of registers and add constants to base registers. If reload can't do that without affecting the dependencies between instructions, then it will break. And I don't think reload will be able to do that between your two instructions above, on a typical cc0 machine in which every move affects the condition codes. Ian
