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
