This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SH: PR target/24445
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: ian at airs dot com (Ian Lance Taylor)
- Cc: kkojima at rr dot iij4u dot or dot jp (Kaz Kojima), joern dot rennecke at st dot com, gcc at gcc dot gnu dot org, aoliva at redhat dot com
- Date: Wed, 2 Nov 2005 20:55:19 -0500 (EST)
- Subject: Re: SH: PR target/24445
>
> Kaz Kojima <kkojima@rr.iij4u.or.jp> writes:
>
> > --- ORIG/trunk/gcc/calls.c 2005-10-29 06:52:11.000000000 +0900
> > +++ LOCAL/trunk/gcc/calls.c 2005-11-03 09:15:47.000000000 +0900
> > @@ -2774,6 +2774,17 @@ expand_call (tree exp, rtx target, int i
> > emit_insn (insns);
> > valreg = temp;
> > }
> > + /* We have to copy a return value in a CLASS_LIKELY_SPILLED hard
> > + reg to a plain register, even for pure functions. */
> > + else if (pass && (flags & ECF_PURE)
> > + && REGNO (valreg) < FIRST_PSEUDO_REGISTER
> > + && CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (valreg))))
> > + {
> > + rtx temp = gen_reg_rtx (GET_MODE (valreg));
> > +
> > + emit_move_insn (temp, valreg);
> > + valreg = temp;
> > + }
> >
> > /* For calls to `setjmp', etc., inform flow.c it should complain
> > if nonvolatile values are live. For functions that cannot return,
>
> I don't see what this has to do with pure functions.
It most likely has nothing fully to do with pure functions except
that you can schedule instructions more over them and (I think)
combine over them. Which is where the issue comes in.
-- Pinski