[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 31 Jan 2023, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
> 
> --- Comment #10 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
> (In reply to rsandifo@gcc.gnu.org from comment #9)
> > Are we sure this is a vectoriser vs. C vectors thing?
> 
> it's not, the issue we're debating is how to fix it.
> 
> As Richi pointed out https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583#c4 we
> can fix the vectorizer case by adding a guard around the recog code in the
> vectorizer.
> 
> But that only fixes the vectorizer, and Richi asked why that wasn't enough, to
> which I pointed out it's because intrinsics code hits it as well.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583#c5
> 
> This is why I mentioned that there are two ways to fix this:
> 
> 1. We make the hook less general, and add checks in every place it is called.
> 2. We keep the hook general and pass enough context to the hook for it to
> decide how to optimize the division.

I don't think passing in for example the tree operand 0 helps, the
target appearantly wants to not specialize by the constant divided by
but instead also by the number divided (of we already know its type).

Do you plan to do SSA def pattern matching in the hook for this at
expand time?

As said, recognizing the special case and open-coding the full divison
in the vectorizer (or possibly even from RTL expansion) would be
another option here.