On Mon, May 25, 2020 at 8:00 PM Uros Bizjak <ubiz...@gmail.com> wrote:
>
> On Mon, May 25, 2020 at 1:56 PM Hongtao Liu <crazy...@gmail.com> wrote:
> >
> > On Mon, May 25, 2020 at 7:36 PM Richard Biener <rguent...@suse.de> wrote:
> > >
> > > On Mon, 25 May 2020, Uros Bizjak wrote:
> > >
> > > > On Mon, May 25, 2020 at 8:27 AM Richard Biener <rguent...@suse.de> 
> > > > wrote:
> > > > >
> > > > > On May 25, 2020 8:12:12 AM GMT+02:00, Uros Bizjak <ubiz...@gmail.com> 
> > > > > wrote:
> > > > > >On Mon, May 25, 2020 at 7:53 AM Hongtao Liu <crazy...@gmail.com> 
> > > > > >wrote:
> > > > > >
> > > > > >> > We have to introduce a new expander, that will have conforming 
> > > > > >> > mode
> > > > > >of
> > > > > >> > output operand (V2SF) and will produce RTX that will match
> > > > > >> > *float<floatunssuffix>v2div2sf2. A paradoxical output subreg from
> > > > > >> > V2SFmode V4SFmode is needed, generated by simplify_gen_subreg as 
> > > > > >> > is
> > > > > >> > the case with paradoxical input subreg.
> > > > > >>
> > > > > >> Problem`is simplify_gen_subreg (V4SFmode, operands[0], V2SFmode, 0)
> > > > > >> will return NULL since
> > > > > >> ----
> > > > > >> 948  /* Subregs involving floating point modes are not allowed to
> > > > > >> 949     change size.  Therefore (subreg:DI (reg:DF) 0) is fine, but
> > > > > >> 950     (subreg:SI (reg:DF) 0) isn't.  */
> > > > > >
> > > > > >But, we are not changing size, we are still operating with SFmode. It
> > > > > >looks to me that this limitation is too strict, the intention is to
> > > > > >not expand scalar SFmode to DFmode.
> > > > >
> > > > > I guess so. The test probably wants to tes the component mode.
> > > >
> > > > There is already some fishy x86 specific workaround in place, which I
> > > > took the liberty to extend to vector modes. The attached patch that
> > > > exercises this code works as expected, and produces expected code.
> > > >
> > > > Liu, can you please test the attached patch?
> > > >
> >
> > Bootstrap is ok, regression test for i386/x86-64 backend is ok.
>
> Nice. Will you ammend the ChangeLog and commit the patch?
>

Sure, i'll wait 24 hours in case there's other comments, then i'll
submit the patch.

> > > > Richi, is the middle end part OK?
> > >
> > > +     i.e. (subreg:V4SF (reg:SF) 0) or (subreg:V4SF (reg:V2SF) 0).  This
> > > +     surely isn't the cleanest way to represent this.  It's questionable
> > > +     if this ought to be represented at all -- why can't this all be
> > > hidden
> > > +     in post-reload splitters that make arbitrarily mode changes to the
> > > +     registers themselves.  */
> > > +  else if (VECTOR_MODE_P (omode)
> > > +          && (GET_MODE_INNER (omode) == imode
> > > +              || (VECTOR_MODE_P (imode)
> > > +                  && (GET_MODE_INNER (omode) == GET_MODE_INNER
> > > (imode)))))
> > >      ;
> > >
> > > I'd formulate this simpler, as
> > >
> > >   else if (VECTOR_MODE_P (omode)
> > >            && GET_MODE_INNER (omode) == GET_MODE_INNER (imode))
> > >
> >
> > I think they are functionally the same, so i won't bother to run
> > another round test.
>
> That is correct.
>
> Thanks,
> Uros.



-- 
BR,
Hongtao

Reply via email to