This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 4.2 reload infrastructure (PR 25027)


On Mon, 2005-11-28 at 18:56 -0500, John David Anglin wrote:
> Bernd,
> 
> I have a couple of questions regarding your patch.
> 
> > @@ -5585,28 +5582,33 @@
> >    if (flag_pic
> >        && GET_MODE_CLASS (mode) == MODE_INT
> >        && FP_REG_CLASS_P (class)
> > -      && (GET_CODE (in) == CONST_INT || GET_CODE (in) == CONST_DOUBLE))
> > -    return R1_REGS;
> > +      && (GET_CODE (x) == CONST_INT || GET_CODE (x) == CONST_DOUBLE))
> > +    {
> > +      gcc_assert (mode == SImode || mode == DImode);
> > +      sri->icode = (mode == SImode ? CODE_FOR_reload_insi_pic_const
> > +		    : CODE_FOR_reload_indi_pic_const);
> > +      return NO_REGS;
> 
> I guess these always have to be input reloads.  However, we also have 
> reload_in patterns for SFmode and DFmode.  There weren't any regressions
> in the testsuite but I'm not sure why these modes can't occur as well.
> So, I'm wondering if we need to handle the %r1 case for these modes.
Note this appears to be referring to FP registers in integer modes, not
in FP modes.  In this case we need r1 so that we can compute the address
of the constant pool.


> 
> Possibly, these are handled in another way:
> 
> ;; This must come before the movsf pattern, and it must be present
> ;; to handle obscure reloading cases.
> (define_insn ""
>   [(set (match_operand:SF 0 "register_operand" "=?r,f")
> 	(match_operand:SF 1 "" "?F,m"))]
>   "GET_CODE (operands[1]) == CONST_DOUBLE
>   ...
> 
> >    if (class != R1_REGS && is_symbolic)
> > -    return R1_REGS;
> > +    {
> > +      gcc_assert (mode == SImode || mode == DImode);
> > +      sri->icode = (mode == SImode ? CODE_FOR_reload_insi_pic_const
> > +		    : CODE_FOR_reload_indi_pic_const);
> > +      return NO_REGS;
> > +    }
> 
> Same question here.
Certainly the code to handle this case and the case above should be
shared if it can be done so cleanly.  They're both handling the same
fundamental case -- loading a constant into an FP register, what's
changing is the mode of the FP register.


Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]