gt; 1;
> +*/
> +
> +int
> +f (unsigned int *tmp)
> +{
> + int sum = 0;
> + for (int i = 0; i < 4; i++)
> +sum += tmp[i];
> +
> + return (unsigned int) sum >> 1;
> +}
> --
> 2.34.1
>
>
> From
t: Re: [PATCH] AArch64: Do not increase the vect reduction latency by
multiplying count [PR110625]
Hi Richard,
Update the patch with a simple case (see below case and comments). It shows a
live stmt may not have reduction def, which introduce the ICE.
Is it OK for trunk?
Fix the assertion failu
lt; 4; i++)
+sum += tmp[i];
+
+ return (unsigned int) sum >> 1;
+}
--
2.34.1
From: Hao Liu OS
Sent: Tuesday, August 1, 2023 17:43
To: Richard Sandiford
Cc: Richard Biener; GCC-patches@gcc.gnu.org
Subject: Re: [PATCH] AArch64: Do not increase the vect
--
2.40.0
From: Richard Sandiford
Sent: Monday, July 31, 2023 17:11
To: Hao Liu OS
Cc: Richard Biener; GCC-patches@gcc.gnu.org
Subject: Re: [PATCH] AArch64: Do not increase the vect reduction latency by
multiplying count [PR110625]
Hao Liu OS writes:
>> Which test case do you see this for
PATCH] AArch64: Do not increase the vect reduction latency by
multiplying count [PR110625]
Hao Liu OS writes:
>> Which test case do you see this for? The two tests in the patch still
>> seem to report correct latencies for me if I make the change above.
>
> Not the newly added
Hao Liu OS writes:
>> Which test case do you see this for? The two tests in the patch still
>> seem to report correct latencies for me if I make the change above.
>
> Not the newly added tests. It is still the existing case causing the
> previous ICE (i.e. assertion problem): gcc.target/aarch64
2023 1:35
To: Hao Liu OS
Cc: Richard Biener; GCC-patches@gcc.gnu.org
Subject: Re: [PATCH] AArch64: Do not increase the vect reduction latency by
multiplying count [PR110625]
Sorry for the slow response.
Hao Liu OS writes:
>> Ah, thanks. In that case, Hao, I think we can avoid the ICE by
*/
> ops->reduction_latency = MAX (ops->reduction_latency, base * count);
> else
> ops->reduction_latency = MAX (ops->reduction_latency, base);
>
> Thanks,
> Hao
>
> ________________
> From: Richard Sandiford
> S
p; vect_is_reduction (stmt_info))
instead of using a null check.
I see that vectorizable_reduction calculates a reduc_chain_length.
Would it be OK to store that in the stmt_vec_info? I suppose the
AArch64 code should be multiplying by that as well. (It would be a
separate patch from this one th
s->reduction_latency, base * count);
else
ops->reduction_latency = MAX (ops->reduction_latency, base);
Thanks,
Hao
From: Richard Sandiford
Sent: Wednesday, July 26, 2023 17:14
To: Richard Biener
Cc: Hao Liu OS; GCC-patches@gcc.gnu.org
S
On Wed, Jul 26, 2023 at 12:12 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Wed, Jul 26, 2023 at 11:14 AM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener writes:
> >> > On Wed, Jul 26, 2023 at 4:02 AM Hao Liu OS via Gcc-patches
> >> > wrote:
> >> >>
> >> >> > When was STM
Richard Biener writes:
> On Wed, Jul 26, 2023 at 11:14 AM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Wed, Jul 26, 2023 at 4:02 AM Hao Liu OS via Gcc-patches
>> > wrote:
>> >>
>> >> > When was STMT_VINFO_REDUC_DEF empty? I just want to make sure that
>> >> > we're not pape
educ_def != PHI_RESULT (reduc_def_phi))
loop.
> I see that vectorizable_reduction calculates a reduc_chain_length.
> Would it be OK to store that in the stmt_vec_info? I suppose the
> AArch64 code should be multiplying by that as well. (It would be a
> separate patch from this one though.)
I don'
mp; vect_is_reduction (stmt_info))
instead of using a null check.
I see that vectorizable_reduction calculates a reduc_chain_length.
Would it be OK to store that in the stmt_vec_info? I suppose the
AArch64 code should be multiplying by that as well. (It would be a
separate patch from this one thoug
ing the reduction have
STMT_VINFO_REDUC_DEF set,
only the last (latch def) and live stmts have at the moment.
Richard.
> Thanks,
> Hao
>
> ____________
> From: Richard Sandiford
> Sent: Tuesday, July 25, 2023 17:44
> To: Hao Liu OS
> Cc: GCC-patches@gcc.gnu.org
> Subject: Re: [
VECTYPE (stmt_info): 0x0
Thanks,
Hao
From: Richard Sandiford
Sent: Tuesday, July 25, 2023 17:44
To: Hao Liu OS
Cc: GCC-patches@gcc.gnu.org
Subject: Re: [PATCH] AArch64: Do not increase the vect reduction latency by
multiplying count [PR110625]
Hao Liu OS writes:
> Hi,
>
> Tha
Hao Liu OS writes:
> Hi,
>
> Thanks for the suggestion. I tested it and found a gcc_assert failure:
> gcc.target/aarch64/sve/cost_model_13.c (internal compiler error: in
> info_for_reduction, at tree-vect-loop.cc:5473)
>
> It is caused by empty STMT_VINFO_REDUC_DEF.
When was STMT_VINFO_REDU
ied by the count for
+ single_defuse_cycle. */
+
+long
+f (long res, short *ptr1, short *ptr2, int n)
+{
+ for (int i = 0; i < n; ++i)
+res += (long) ptr1[i] << ptr2[i];
+ return res;
+}
--
2.34.1
________
From: Richard Sandiford
Sent: Monda
Hao Liu OS writes:
> This only affects the new costs in aarch64 backend. Currently, the reduction
> latency of vector body is too large as it is multiplied by stmt count. As the
> scalar reduction latency is small, the new costs model may think "scalar code
> would issue more quickly" and increa
increase the vect reduction latency by
multiplying count [PR110625]
This only affects the new costs in aarch64 backend. Currently, the reduction
latency of vector body is too large as it is multiplied by stmt count. As the
scalar reduction latency is small, the new costs model may think "scalar
This only affects the new costs in aarch64 backend. Currently, the reduction
latency of vector body is too large as it is multiplied by stmt count. As the
scalar reduction latency is small, the new costs model may think "scalar code
would issue more quickly" and increase the vector body cost a lo
21 matches
Mail list logo
