Re: condition codes, haifa-sched and virtual-stack-vars

[Greg McGary <greg@mcgary.org>]

law@redhat.com writes:

> If arithmetic clobbers the register, then that needs to be reflected in
> the RTL for arithmetic.

It is.  FYI, here's the addsi3 pattern:

        (define_insn_and_split "addsi3"
          [(set (match_operand:SI 0 "register_operand"          "=r,r,r,r,r,r,r")
        	(plus:SI (match_operand:SI 1 "register_operand" "%0,0,0,0,0,0,0")
        		 (match_operand:SI 2 "uimm32r_operand"   "rM,U,I,S,K,T,P")))
           (clobber (reg:CC CC_REGNUM))]

All other arithmetic patterns are similar.

Here's a summary of mutations, by optimizer phase.

00.rtl:
    We pass the address of stack var, which hapens to be the first one
    allocated, so it's a zero-offset form virtual-stack-vars

        (insn 1299 1297 1301 (set (reg/v:SI 397)
                (reg/f:SI 46 virtual-stack-vars)) -1 (nil)
            (nil))

03.jump:
    Nothing interesting here

	(insn 1299 1297 1301 (set (reg/v:SI 397)
	        (reg/f:SI 32 TempFP)) 8 {*movsi} (nil)
	    (nil))

18.sched:
    Haifa relocates this insn to sit between setting CC and cond branch:

        (insn 1299 3891 1301 (set (reg/v:SI 397)
                (reg/f:SI 32 TempFP)) 8 {*movsi} (nil)
            (nil))

20.greg:
    TempFP is eliminated in favor of real fp+offset, and now the set is no longer innocent.

        (insn 4102 3891 4103 (set (reg:SI 2 r2)
                (const_int 56 [0x38])) 8 {*movsi} (nil)
            (nil))

        (insn 4103 4102 1299 (parallel[ 
                    (set (reg:SI 2 r2)
                        (plus:SI (reg:SI 2 r2)
                            (reg/f:SI 28 r28)))
                    (clobber (reg:CC 34 CC))
                ] ) 19 {addsi3} (nil)
            (expr_list:REG_EQUIV (plus:SI (reg/f:SI 28 r28)
                    (const_int 56 [0x38]))
                (nil)))

        (insn 1299 4103 1301 (set (reg/v:SI 12 r12 [397])
                (reg:SI 2 r2)) 8 {*movsi} (nil)
            (expr_list:REG_EQUIV (plus:SI (reg/f:SI 28 r28)
                    (const_int 56 [0x38]))
                (nil)))

22.flow2:
    Flow notices that the legitimate set of CC has its result clobbered, so 
    removes all of the legitimate bitfield code.

Things would have been OK if the stack var weren't the first one,
so that it got an offset in 00.rtl, and the associated clobber.
Maybe we shouldn't emit bare virtual-stack-vars, but rather emit as
plus with 0 offset?

Something else entirely?

Thanks,
Greg