https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #29 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to rguent...@suse.de from comment #28)
> On Mon, 26 Feb 2024, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
> >
> > --- Comment #27 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
> > Created attachment 57538 [details]
> > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57538&action=edit
> > proposed1.patch
> >
> > proposed patch, this gets the gathers and scatters back. doing regression
> > run.
>
> I don't think this will fly.
Well.. I don't really know what the do here I guess.
per the discussion on irc, we only used to try gather/scatters when SCEV fails.
Now that it succeeds we no longer try using the pattern and try to handle it
during vectorizable_load/vectorizable_stores as recognizing the gather/scatters
inline through VMAT_GATHER_SCATTER.
This works fine for normal gather and scatters but doesn't work for widening
gathers and narrowing scatters which only the pattern seems to handle.
I don't know how to get this to be detected through get_load_store_type since
well, that's very late. among others we've already determined the VF and the
unpacks have already been marked relevant. So
vectorizable_load/vectorizable_store would have to actively change the IL.
So I don't know how widening and narrowing operations are supposed to work
here. given that.. I will leave it up to the maintainers I guess.
