[PATCH], PR target/93937, Fix variable vec_extract insn that will never match

[Segher Boessenkool]

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?

> But it irks me to have this pattern that mostly was correct, but it would never
> match.  As I see it, there are 4 options:
> 
> 1) Delete the insn completely, since it doesn't match, and then put in code
> later to cover the case when PR target/93230 is done.

Such a patch is pre-approved.

> 3) Patch the existing insns so that they do match, but don't add all of the
> other options that could be added (adding sign extension, adding the ability to
> load the value into vector registers with ISA 2.07, optimizing vec_extract
> being cnverted to floating point to avoid direct moves, etc.).
> 
> 4) Do all of the possibilities now.  The trouble is due to the number of
> special cases, this can add up to a number of new insns (for example, dealing
> with HImode/QImode also being zero extended to SImode in addition to DImode,
> dealing with QImode not having a sign extending load, dealing with SImode that
> can load into the vector registers at ISA 2.05/2.06 which HI/QI modes need
> 2.07, etc.).
> 
> Given we are in stage 4, I think #4 is not appropriate (but if you want, I can
> do the patches).

That goes for option 3 as well.

Thanks,


Segher