Yes. We do have && enable char -> long conversion (vsext.vf8/vzext.vf8)
Thanks for the comment, I will adapt test as you suggested.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-10-09 15:31
To: Jeff Law
CC: Juzhe-Zhong; gcc-patches; richard.sandiford
Subject: Re: [PATCH] TEST: Fix dump FAIL of vect-multitypes-16.c for RVV
On Sun, 8 Oct 2023, Jeff Law wrote:
>
>
> On 10/8/23 05:35, Juzhe-Zhong wrote:
> > RVV (RISC-V Vector) doesn't enable vect_unpack, but we still vectorize this
> > case well.
> > So, adjust dump check for RVV.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/vect/vect-multitypes-16.c: Fix dump FAIL of RVV.
> I'd hoped to avoid a bunch of risc-v special casing in the generic part of the
> testsuite. Basically the more we have target specific conditionals rather
> than conditionals using properties, the more likely we are to keep revisiting
> this stuff over time and possibly for other architectures as well.
>
> What is it about risc-v's vector support that allows it to optimize this case?
> Is it the same property that allows us to handle the outer loop vectorization
> tests that you changed in another patch?
I suspect for VLA vectorization we can use direct conversion from
char to long long here? I also notice the testcase uses 'char',
not specifying its sign. So either of [sz]extVxyzDIVxyzQI is possibly
provided by RISCV? (or possibly via some intermediate types in a
multi-step conversion)
For non-VLA and with the single vector size restriction we'd need
unpacking.
So it might be better
{ target { vect_unpack || { vect_vla && vect_sext_char_longlong } } }
where I think neither vect_vla nor vect_sext_char_longlong exists.
Richard - didn't you run into similar things with SVE?
Richard.
> Neither an ACK nor NAK right now.
>
> Jeff
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
