On 06/11/2023 07:52, Richard Biener wrote:
On Fri, 3 Nov 2023, Andre Vieira (lists) wrote:Hi, The current codegen code to support VF's that are multiples of a simdclone simdlen rely on BIT_FIELD_REF to create multiple input vectors. This does not work for non-constant simdclones, so we should disable using such clones when the VF is a multiple of the non-constant simdlen until we change the codegen to support those. Enabling SVE simdclone support will cause ICEs if the vectorizer decides to use a SVE simdclone with a VF that is larger than the simdlen. I'll be away for the next two weeks, so cant' really discuss this further. I initially tried to solve the problem, but the way vectorizable_simd_clone_call is structured doesn't make it easy to replace BIT_FIELD_REF with the poly-suitable solution right now of using unpack_{hi,lo}.I think it should be straight-forward to use unpack_{even,odd} (it's even/odd for VLA, right? If lo/hi would be possible then doing BIT_FIELD_REF would be, too? Also you need to have multiple stages of unpack/pack when the factor is more than 2). There's plenty of time even during stage3 to address this. At least your patch should have come with a testcase (or two).
Yeah I didn't add one as it didn't trigger on AArch64 without my two outstanding aarch64 simdclone patches.
Is there a bugreport tracking this issue? It should affect GCN as well I guess.
No, since I can't trigger them yet on trunk until the reviews on my target specific patches are done and they are committed.
I don't have a GCN backend lying around but I suspect GCN doesn't use poly simdlen simdclones yet either... I haven't checked. The issue triggers for aarch64 when trying to generate SVE simdclones for functions with mixed types. I'll give the unpack thing a go locally.
