Re: passing information to back-end from source code?

[Michael Poole <poole at troilus dot org>]

Joern Rennecke <amylaar@cygnus.co.uk> writes:

> > > > and then write to a C variable given that register number.  However,
> > > > the regmove pass is moving the constant 0 or 1 into another register
> > > > and then trying to assign to R33 from that register (and so it loses
> > > > the information I wanted to pass).  I cannot see why it does that (or
> > > > even which macros tell GCC that the sequence of loads/moves it
> > > > generates while not generating the obvious "move R33, 0") -- in
> > > > particular, R33 is in its own register class.
> 
> > (define_insn "movqi"
> >   [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,m")
> >         (match_operand:QI 1 "general_operand" "ri,m,r"))]
> 
> Hmm, there is no matching constraint here, so I'm baffled what's going on
> there.  Could you start cc1 under gdb control, set a breakpoint at
> make_insn_raw, and a condition cfun->emit->x_cur_insn_uid ==
> whatever the insn number of the new insn to move the constant to the
> new register is?

The first time that breakpoint/condition pair triggers, it's being
called from init_caller_save (with pattern
  (set (mem:HI (reg:QI 0)) (reg:HI 19))
).  The second (and final) time it triggers seems to be the
interesting one; here it has the expected pattern
  (set (reg:QI 33) (const_int 1))
.  The assembler output of cc1 still has the load through an indirect,
although it looks like it's happening at a different pass than before
(I think due to changing the sing and dance patterns to make reg 33
volatile, rather than having (const_int 0) there).

In taskb.c.18.lreg, I see:
;; Start of basic block 7, registers live: 30 [R30] 31 [R31]
(note 275 79 83 [bb 7] NOTE_INSN_BASIC_BLOCK -1347440721)

(insn 83 275 89 (set (reg/v:QI 33 WF_PTN)
        (const_int 1 [0x1])) 4 {movqi} (nil)
    (expr_list:REG_UNUSED (reg/v:QI 33 WF_PTN)
        (expr_list:REG_EQUAL (const_int 1 [0x1])
            (nil))))

(insn 89 83 91 (set (reg/v:QI 33 WF_PTN)
        (const_int 0 [0x0])) 4 {movqi} (insn_list:REG_DEP_OUTPUT 83 (nil))
    (expr_list:REG_EQUAL (const_int 0 [0x0])
        (nil)))

(jump_insn 91 89 92 (return) 44 {return} (insn_list:REG_DEP_ANTI 83 (insn_list:REG_DEP_ANTI 89 (nil)))
    (nil))
;; End of basic block 7, registers live:
 30 [R30] 31 [R31] 33 [WF_PTN]

Although in taskb.c.19.greg I see:
;; Start of basic block 7, registers live: 30 [R30] 31 [R31]
(note 275 79 83 [bb 7] NOTE_INSN_BASIC_BLOCK -1347440721)

(insn 83 275 89 (set (reg:QI 6 R6)
        (const_int 1 [0x1])) 4 {movqi} (nil)
    (expr_list:REG_EQUAL (const_int 1 [0x1])
        (nil)))

(insn 89 83 303 (set (reg:QI 7 R7)
        (const_int 0 [0x0])) 4 {movqi} (insn_list:REG_DEP_OUTPUT 83 (nil))
    (expr_list:REG_EQUAL (const_int 0 [0x0])
        (nil)))

(insn 303 89 91 (set (reg/v:QI 33 WF_PTN)
        (reg:QI 7 R7)) 4 {movqi} (nil)
    (nil))

(jump_insn 91 303 92 (return) 44 {return} (insn_list:REG_DEP_ANTI 83 (insn_list:REG_DEP_ANTI 89 (nil)))
    (nil))
;; End of basic block 7, registers live:
 30 [R30] 31 [R31] 33 [WF_PTN]

So appears that global register allocation is for some reason changing
the writes into the volatile register (and later the store of 1 to reg
6 is being eliminated).

Michael