On Fri, Feb 28, 2020 at 06:45:25AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Feb 28, 2020 at 12:32:06AM -0500, Michael Meissner wrote:
> > As part of my work in adding support for -mcpu=future, I noticed an insn
> > that
> > would never match.
>
> > It will never match, because the zero_extend result is the same mode as the
> > input, so the machine independent parts of the compiler would never insert
> > the
> > zero extend.
>
> It's not valid RTL, even:
> @findex zero_extend
> @item (zero_extend:@var{m} @var{x})
> Represents the result of zero-extending the value @var{x}
> to machine mode @var{m}. @var{m} must be a fixed-point mode
> and @var{x} a fixed-point value of a mode narrower than @var{m}.
>
> > There is a wider issue to optimize all cases of vec_extract to do the sign,
> > zero, and float extension automatically when we are loading from memory,
> > which
> > is PR target/93230. I have patches for all of the cases for 93230, but they
> > will need to wait until GCC 11 opens up.
>
> If you don't use reload_completed in the split condition you do not have
> this problem (in the normal case). Please work on that?
No. I tend to think that if we do the split before reload, that it will cause
some regressions, because the register allocator will take the opportunity to
change loads to vector registers to be loads to GPRs and direct moves. One of
the original motivations for some of these patches is to avoid direct moves.
I also worry that things like having to use SUBREG's before RA (instead of just
changing the mode and/or the register number that we can do after reload) will
not work because generally vectors and scalars aren't tieable.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
