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
