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.
("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
