On 22 February 2012 00:24, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > Ayonam Ray <ayonam@xxxxxxxxx> writes: > >> Register r0 is set to zero as per software conventions. Hence, it is >> made a fixed register. > > If r0 is a fixed 0, then you should never set it to anything else in > RTL. Doing so will inhibit some optimizations. You should invent a new > register, one that does not exist in hardware, for this purpose. > > >> (define_insn "mvc_to_ccr" >> [(unspec_volatile:SI [(match_operand:SI 0 "register_operand" "=Y") >> (match_operand:SI 1 "register_operand" "r")] >> UNSPEC_MVC_TO_CCR) >> (set (reg:SI 0) (unspec_volatile [(reg:SI 0)]UNSPEC_CCR))] >> "" > > >> (insn 15 14 16 g.c:980 (parallel [ >> (unspec_volatile:SI [ >> (reg:SI 98 ccr8) >> (reg:SI 124) >> ] 28) >> (set (reg:SI 1 r1) >> (const_int 0 [0x0])) >> ]) -1 (nil)) > > The define_insn says (set (reg:SI 0) (unspec_volatile ...)). The RTL > dump says (set (reg:SI 1) (const_int 0)). Why the difference? > >> P.S.: Are attachments allowed on the GCC mailing lists? > > I think so, but they can't be too large. > > Ian Ian, I created a dummy register number 107 at the end of the register file and used that to do what you suggested. The RTL generated after expand at -O2 is attached herewith. The results are the same as before. What I can't understand is that why is the RTL reordered right at the expand stage itself. If I turn off the optimization, then the reorder at the expand stage doesn't happen. This can be seen in the expand output at -O0. I am wondering if there is some issue with the manner in which the built-ins are initialized which makes the compiler think that they do not affect program state. Regards Ayonam
Attachment:
g.c.141r.expand_O0
Description: Binary data
Attachment:
g.c.141r.expand_O2
Description: Binary data
