Re: [PATCH, rev 2] PR target/79799, Add vec_insert of V4SFmode on PowerPC ISA 3.0 (power9)

[Segher Boessenkool <segher@kernel.crashing.org>]

On Fri, Jun 16, 2017 at 04:26:58PM -0400, Michael Meissner wrote:
> > > +  "&& reload_completed"
> > 
> > I still don't think it is such a good idea to do all of this not until
> > after reload.  It does of course allow you to play tricks with changing
> > register mode at will, like you do ;-)
> 
> The problem is MODES_TIEABLE_P.  V4S{I,F}mode and SImode cannot be tied
> together (i.e. use gen_lowpart to change the mode and use a SUBREG).  So after
> reload, we can just use gen_rtx_REG (...) to change the register type, but
> before reload, by creating the SUBREG, it can lead to various aborts if rtl
> checking is turned on.

That sounds like a problem elsewhere?  Hrm.

> > All these unspecs are a similar problem: the RTL optimisers cannot do
> > much at all with it.
> 
> I don't think there is a good way to represent a vec_insert.  And vec_extract
> can't represent a variable extract either.

Yeah.  But especially for all this lane shuffling etc. the generic
optimisers could do a good job, if only they knew how.  Maybe we need
some new RTL codes.

> > > +  [(set_attr "type" "vecperm")
> 
> > Is that a good type for this?  I think the convert is more expensive
> > than the permutes?  If so, that would be better (of course it only
> > matters for sched1, not super important).
> 
> I generally use the type of the last insn.  I am open to other suggestions.

It should describe the resulting insns as a whole.  Picking the type of
the most expensive insn is often a reasonable approximation; for integer
insns "two" or "three" can be okay.

I don't think we can do much better currently.


Segher