Thanks Robin for comments. > I agree with the general idea but I'm a bit wary fiddling with the > coefficients > directly. I think for a fixed-size, non VLA vector it should be sufficient to > check whether the last step overflows.
Initial idea I would like to take care of VLS and VLA in the same chunk of code, given the expand_const_vector is sort of complicated currently(I don't want to make it worse by add more if VLA, else if VLS ... etc). I will try to leverage poly_int mult, shift, and compare if possible, instead of touch the coefficients directly in v2. > For VLA we actually know the largest possible runtime vector length and could > use it the check? But maybe it's probably easier to bail with VLA anyway. > In addition: if we're already checking the step anyway we could get rid of the > negative step restriction as well. I don't explore more cases here consider we are in stage 4. I think the expand_const_vector need some refactor up to a point. Pan -----Original Message----- From: Robin Dapp <rdapp....@gmail.com> Sent: Monday, February 24, 2025 4:29 PM To: Li, Pan2 <pan2...@intel.com>; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; Robin Dapp <rdapp....@gmail.com> Subject: Re: [PATCH v1] RISC-V: Fix bug for expand_const_vector interleave [PR118931] > This patch would like to perform the overflow to smode check before IOR > the base2 series, and perform the clean highest bit if the const_vector > overflow to smode occurs. If no overflow, there will do nothing here. I agree with the general idea but I'm a bit wary fiddling with the coefficients directly. I think for a fixed-size, non VLA vector it should be sufficient to check whether the last step overflows. For VLA we actually know the largest possible runtime vector length and could use it the check? But maybe it's probably easier to bail with VLA anyway. In addition: if we're already checking the step anyway we could get rid of the negative step restriction as well. -- Regards Robin
