On Thu, May 10, 2018 at 05:20:52PM -0500, Segher Boessenkool wrote:
> On Thu, May 10, 2018 at 05:49:12PM -0400, Michael Meissner wrote:
> > > > -/* Return true if we have D-form addressing in altivec registers.  */
> > > > +/* Return true if we have D-form addressing (register+offset) in 
> > > > either a
> > > > +   specific reload register class or whether some reload register class
> > > > +   supports d-form addressing.  */
> > > >  static inline bool
> > > > -mode_supports_vmx_dform (machine_mode mode)
> > > > +mode_supports_d_form (machine_mode mode,
> > > > +                     enum rs6000_reload_reg_type rt = RELOAD_REG_ANY)
> > > >  {
> > > > -  return ((reg_addr[mode].addr_mask[RELOAD_REG_VMX] & 
> > > > RELOAD_REG_OFFSET) != 0);
> > > > +  return ((reg_addr[mode].addr_mask[rt] & RELOAD_REG_OFFSET) != 0);
> > > >  }
> > > 
> > > Will this overload help anything?  It does not look that way, all current
> > > callers use a different argument (and all the same).
> > 
> > All current callers just use the ANY option (except for these calls).  
> > However
> > in the future, I'm planning on calling these functions with the specific 
> > reload
> > register class (hence the change).
> 
> No, they use RELOAD_REG_VMX.  Unless there is something extra tricky
> about your patch?

Yes, point is to make it more general.

Right now, mode_supports_vmx_dform is only called to see if we have the ISA 3.0
d/ds/dq-form instructions.  It is called in secondary reload to see if a
register supports d*-form insns.  It is also called in preferred reload class
to say whether we would prefer just a FPR register for a d*-form insn or we can
also tolerate a VMX register.

However, as I contemplate reworking the memory support, I want to clean up a
lot of the code that knows certain modes can do certain address forms.  I'm
getting to hate code like:

        if (mode == SFmode || mode == DFmode || ...)

So I was just trying to clean things up, and migratate to using the
reg_addr[mode].addr_mask bits.  Having the inline functions can also make the
line length smaller.

--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Reply via email to