On Mon, Sep 27, 2021 at 11:42 AM Hongtao Liu <crazy...@gmail.com> wrote:
>
> On Fri, Sep 24, 2021 at 9:08 PM Segher Boessenkool
> <seg...@kernel.crashing.org> wrote:
> >
> > On Mon, Sep 13, 2021 at 04:24:13PM +0200, Richard Biener wrote:
> > > On Mon, Sep 13, 2021 at 4:10 PM Jeff Law via Gcc-patches
> > > <gcc-patches@gcc.gnu.org> wrote:
> > > > I'm not convinced that we need the inner mode to match anything. As
> > > > long as the vec_concat's mode is twice the size of the vec_select modes
> > > > and the vec_select mode is <= the mode of its operands ISTM this is
> > > > fine. We might want the modes of the vec_select to match, but I don't
> > > > think that's strictly necessary either, they just need to be the same
> > > > size. ie, we could have somethig like
> > > >
> > > > (vec_concat:V2DF (vec_select:DF (reg:V4DF)) (vec_select:DI (reg:V4DI)))
> > > >
> > > > I'm not sure if that level of generality is useful though. If we want
> > > > the modes of the vec_selects to match I think we could still support
> > > >
> > > > (vec_concat:V2DF (vec_select:DF (reg:V4DF)) (vec_select:DF (reg:V8DF)))
> > > >
> > > > Thoughts?
> > >
> > > I think the component or scalar modes of the elements to concat need to
> > > match
> > > the component mode of the result. I don't think you example involving
> > > a cat of DF and DI is too useful - but you could use a subreg around the
> > > DI
> > > value ;)
> >
> > I agree.
> >
> > If you want to concatenate components of different modes, you should
> > change mode first, using subregs for example.
> I don't really understand.
>
> for
> > > > (vec_concat:V2DF (vec_select:DF (reg:V4DF)) (vec_select:DF (reg:V8DF)))
> > > >
> > > > Thoughts?
> how can it be simplified when reg:V4DF is different from (reg:V8DF)
> to
> (vec_select: (vec_concat:(subreg V8DF (reg:V4DF) 0) (reg:V8DF))
> (paralle[...])
> ?, which doesn't look like a simpication.
>
> Similar for
> > > > (vec_concat:V2DF (vec_select:DF (reg:V4DF)) (vec_select:DI (reg:V4DI)))
>
> here we require rtx_equal_p (XEXP (trueop0, 0), XEXP (trueop1, 0)) so
> vec_concat (vec_select vec_select) can be simplified to just
> vec_select.
Yes, I think your patch is reasonable, I don't understand how we can
intermediately convert here either or how that would help.
Quoting the original example:
(set (reg:V2DF 87 [ xx ])
(vec_concat:V2DF (vec_select:DF (reg:V4DF 92)
(parallel [
(const_int 2 [0x2])
]))
(vec_select:DF (reg:V4DF 92)
(parallel [
(const_int 3 [0x3])
]))))
it's not about vec_concat of different modes but vec_concat with V2DF
mode concated from vec_select of V4DF and V2DF and V4DF not matching
up. But we can do (vec_select:V2DF (reg:V4DF ..) (parallel [... ])) just
fine which this case doesn't handle.
Richard.
>
> >
> > ("Inner mode" is something of subregs btw, "component mode" is what this
> > concept of modes is called, the name GET_MODE_INNER is a bit confusing
> > though :-) )
> >
> > Btw, the documentation for "concat" says
> > @findex concat
> > @item (concat@var{m} @var{rtx} @var{rtx})
> > This RTX represents the concatenation of two other RTXs. This is used
> > for complex values. It should only appear in the RTL attached to
> > declarations and during RTL generation. It should not appear in the
> > ordinary insn chain.
> > which needs some updating (in many ways).
> >
> >
> > Segher
>
>
>
> --
> BR,
> Hongtao
