> > Index: gcc/cfgexpand.c > > =================================================================== > > --- gcc/cfgexpand.c (revision 201184) > > +++ gcc/cfgexpand.c (working copy) > I thought I already approved this. Go ahead and install it.
Sorry, I forgot to split out those three patches when I diffed. > > Index: gcc/simplify-rtx.c > > =================================================================== > > --- gcc/simplify-rtx.c (revision 201184) > > +++ gcc/simplify-rtx.c (working copy) > Testcase? Explanation? This seems like you're papering over a bug. Likewise. > > Index: gcc/dwarf2cfi.c > So was there a discussion of this patch? Presumably BITS_PER_WORD is 16 > and you've got 20 bit pointers which causes this problem, right? I don't recall any discussion. Right, pointers are bigger than words. > I think you should go ahead and install this patch as well. Ok. > > +; Note: using POPM.A #1 is two bytes smaller than using POPX.A.... > > + > > +(define_insn "movsipsi2" > > + [(set (match_operand:PSI 0 "register_operand" "=r") > > + (subreg:PSI (match_operand:SI 1 "register_operand" "r") 0))] > > + "TARGET_LARGE" > > + "PUSH.W %H1 { PUSH.W %1 { POPM.A #1, %0" > > +) > So how is this different fram > (set (psi) (truncate:psi (si)))? It should be the same, of course. I typically look at what gcc *is* generating, not what it *should* be generating, though ;-) GCC does a lot of silly things these days. > > +; This pattern is needed in order to avoid reload problems. > > +; It takes an SI pair of registers, adds a value to them, and > > +; then converts them into a single PSI register. > > + > > +(define_insn "addsipsi3" > > + [(set (subreg:SI (match_operand:PSI 0 "register_operand" "=&r") 0) > > + (plus:SI (match_operand:SI 1 "register_operand" "0") > > + (match_operand 2 "general_operand" "rmi"))) > > + (clobber (reg:CC CARRY)) > > + ] > > + "" > > + "ADD.W\t%L2, %L0 { ADDC.W\t%H2, %H0 { PUSH.W %H0 { PUSH.W %L0 { POPM.A > > #1, %0" > > + > Is it possible the insns which resulted in adding this pattern came from > trying to zero/sign extend the frame pointer, then the frame pointer > gets eliminated and turns into a (plus (sp) (const_int)? It's possible that's one case, but *all* pointer math happens in SImode since the pointer_plus change went in. So this pattern happens a lot.