> and basically adding a new clause here. That would make us fall back to the
> merge scheme in case of overflow instead of making the other scheme more
> complicated.
Oh, I see, that make sense to me, given current implementation of
expand_const_vector is complicated, let me update in v4.
Pan
-----Original Message-----
From: Robin Dapp <rdapp....@gmail.com>
Sent: Thursday, February 27, 2025 1:37 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 v2] RISC-V: Fix bug for expand_const_vector interleave
[PR118931]
> If you mean the last branch of interleave, I think it is safe because it
> leverage the
> merge to generate the result, instead of IOR. Only the IOR for final result
> have
> this issue.
Yep, I meant checking overflow before the initial if
if (known_ge (step1, 0) && known_ge (step2, 0)
&& int_mode_for_size (new_smode_bitsize, 0).exists (&new_smode)
&& get_vector_mode (new_smode, new_nunits).exists (&new_mode))
and basically adding a new clause here. That would make us fall back to the
merge scheme in case of overflow instead of making the other scheme more
complicated.
I haven't checked this but could imagine the merge sequence is not worse or
even preferable.
--
Regards
Robin
