Re: Reload pass ignores constraints. Why?

[Georg-Johann Lay <avr at gjlay dot de>]

Ian Lance Taylor schrieb:
> Georg-Johann Lay <avr@gjlay.de> writes:
>
> > Working out recommendations for a new instruction set architecture (no
> > silicon yet), I run into the following problem with a port based on
> > gcc_4_3_3_release: postreload complains
>
> > From your description, I would have expected reload to handle this
> correctly.  I don't know why it didn't.  The first place to look would
> be to verify that the REG_CLASS_CONTENTS bitmasks are correct.  Next,
> look at the .greg dump to see if the insn in question required any
> reloads.  If not, the next step may be to debug find_reloads to find out
> why no reloads were required.  This can somewhat tedious; you can set a
> breakpoint to match the insn UID so that you are looking at the right
> insn in find_reloads, but following the loops can still take a while.
> Good luck.  I've spent many days on this sort of problem.
>
> Ian

Hi Ian,

greg does not generate reloads for the insn in question (the {lshrsi3}), 
and find_reloads is never called for it.

I guess the caller should be reload1.c::calculate_needs_all_insns?

When calculate_needs_all_insns runs on the insn the insn looks like this 
(other insn numbers than above as I proceed my very work regardless of 
the possible bug)

calculate_needs_all_insns[__kernel_rem_pio2:greg(180)]: (insn:HI 409 438 
400 17 k_rem_pio2.c:816 (set (reg:SI 566)
        (lshiftrt:SI (reg:SI 0 d0 [565])
            (const_int 8 [0x8]))) 22 {lshrsi3} (expr_list:REG_EQUIV 
(const_int 16777215 [0xffffff])
        (expr_list:REG_DEAD (reg:SI 0 d0 [565])

Someone already replaced #1 with d0, a reg of the right class "d". Maybe 
a function parameter or return value is propagated.

However, calculate_needs_all_insns decides that there are no reloads 
needed. reload1.c:1554 reads:

	  /* Skip insns that only set an equivalence.  */
	  if (set && REG_P (SET_DEST (set))
	      && reg_renumber[REGNO (SET_DEST (set))] < 0
	      && (reg_equiv_constant[REGNO (SET_DEST (set))]
		  || (reg_equiv_invariant[REGNO (SET_DEST (set))]))
		      && reg_equiv_init[REGNO (SET_DEST (set))])
              continue;

Before lreg, the insn is tagged REG_EQUAL but lreg then retags it as 
REG_EQUIV.

So is the problem in lreg because it says REG_EQUIV?
Or is it wrong to omit REG_EQUIV insns from reload?

Georg-Johann