So even though our strided loads do support signed strides, we cannot go via
the
recognize gather
-> recognize strided offset
-> strided load
route because the initial signed-offset gather will be unsupported :/
I did want to relax the initial STMT_VINFO_GATHER_SCATTER_P detection
to not require any target support (there's emulated gather after all!). But the
above isn't a gather, it's a strided (group) load anyway.
Yes, and I thought we wanted to recognize these as gather with index {0, 1, 2,
3, stride + 0, stride + 1, stride + 2, stride + 3, ...}? Then change the
element size to 32 so the index becomes {0, stride, stride * 2, ...}, which,
eventually, would be emitted as strided load if supported.
The other option would be to have an alternative to the gather -> strided
connection and additionally check for strided_load support directly? Currently
I see no way around this given the restrictions imposed by our insns.
I think that rather than going via vect_check_gather_scatter in
vect_use_strided_gather_scatters_p we should directly query gather optab
support with the appropriate offset. Don't you have gather optabs like
gatherV4SISI for SImode scalar strides already?
Our gather optabs currently just have vector modes for the index. The
mask_len_strided_load<mode> optab just has the data mode and supports Pmode
strides.
The gather docs also specify the index operand as a vector. Do we want to
relax this and allow a scalar as well? That way we could at least query a
unified optab in the above case, rather than querying both gather_load and
mask_len_strided_load.
--
Regards
Robin
