ate in v4.
Pan
-Original Message-
From: Robin Dapp
Sent: Thursday, February 27, 2025 1:37 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; Robin
Dapp
Subject: Re: [PATCH v2] RISC-V: Fix bug for expand_const_vector interleave
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)
.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; Robin
Dapp
Subject: Re: [PATCH v2] RISC-V: Fix bug for expand_const_vector interleave
[PR118931]
> Thanks Robin.
>
>> - IMHO we need to check both series for overflow, if step2 overflows in the
>> smaller type isn't the re
Thanks Robin.
- IMHO we need to check both series for overflow, if step2 overflows in the
smaller type isn't the result equally wrong?
The series2 will shift right before IOR, thus the overflow bits never effect
on the final result.
For example, the series2 will be similar as below after shift
juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; Robin
Dapp
Subject: Re: [PATCH v2] RISC-V: Fix bug for expand_const_vector interleave
[PR118931]
> This patch would like to fix one bug when expanding const vector for the
> interleave case. For example, we have:
>
> b
> This patch would like to fix one bug when expanding const vector for the
> interleave case. For example, we have:
>
> base1 = 151
> step = 121
>
> For vec_series, we will generate vector in format of v[i] = base + i * step.
> Then the vec_series will have below result for HImode, and we can find
