Help interpreting RTL dumps

[law@redhat.com]

In message <se9ea80a.022@ems.rmit.edu.au>, "Marty Hauff" writes:
 >I'm trying to retarget GCC and it fails during compilation of libgcc2.c  The 
 >RTL dumps are confusing me a little and I can't find any clear info in the "G
 >NU Compiler Collection Internals" documentation about how to interpret them.
 >
 >Output from libgcc2.c.17.ce has:
 >(insn 21 18 22 (set (cc0)
 >        (reg:SI 44)) 287 {tstsi} (nil)
 >    (expr_list:REG_DEAD (reg:SI 44)
 >        (nil)))
 >
 >Output from libgcc2.c.18.regmove turns this into:
 >(insn:QI 21 18 22 (set (cc0)
 >        (reg:SI 44)) 287 {tstsi} (nil)
 >    (expr_list:REG_DEAD (reg:SI 44)
 >        (nil)))
 >
 >The compiler complains about this insn.  I'm a bit confused about the ":QI" a
 >fter the insn bit.  Is this valid and if so does anyone have or know of any d
 >oco that says so?  If its not valid I suppose I'll have to find out why it ge
 >ts changed between these two dumps.
The mode of an insn is generally used within a pass for some kind of
bookkeeping.

A quick "grep QImode regmove.c" gets 3 hits.  

   QImode is used on the instruction at which the flags becomes live.
                  PUT_MODE (insn, QImode);
         result in a QImode clober.  */


Expanding the first hit we see:

/* It is a tedious task identifying when the flags register is live and
   when it is safe to optimize.  Since we process the instruction stream
   multiple times, locate and record these live zones by marking the
   mode of the instructions --
                                                                               

   QImode is used on the instruction at which the flags becomes live.
                                                                               

   HImode is used within the range (exclusive) that the flags are
   live.  Thus the user of the flags is not marked.
                                                                               

   All other instructions are cleared to VOIDmode.  */
                                                                               


Seems like things are working exactly as expected.

You're more likely to get help if you provide more details (like actual
error messages) rather than saying "the compiler complains about this insn".


Jeff