Wilco Dijkstra writes:
> Hi Richard,
>
>>> A smart reassociation pass could form more FMAs while also increasing
>>> parallelism, but the way it currently works always results in fewer FMAs.
>>
>> Yeah, as Richard said, that seems the right long-term fix.
>> It would also avoid the hack of
Hi Richard,
>> A smart reassociation pass could form more FMAs while also increasing
>> parallelism, but the way it currently works always results in fewer FMAs.
>
> Yeah, as Richard said, that seems the right long-term fix.
> It would also avoid the hack of treating PLUS_EXPR as a signal
> of an
Wilco Dijkstra writes:
> Hi Richard,
>
>> I guess an obvious question is: if 1 (rather than 2) was the right value
>> for cores with 2 FMA pipes, why is 4 the right value for cores with 4 FMA
>> pipes? It would be good to clarify how, conceptually, the core property
>> should map to the
Hi Richard,
> I guess an obvious question is: if 1 (rather than 2) was the right value
> for cores with 2 FMA pipes, why is 4 the right value for cores with 4 FMA
> pipes? It would be good to clarify how, conceptually, the core property
> should map to the fma_reassoc_width value.
1 turns off
On Tue, Nov 22, 2022 at 8:59 AM Richard Sandiford via Gcc-patches
wrote:
>
> Wilco Dijkstra writes:
> > Add a reassocation width for FMAs in per-CPU tuning structures. Keep the
> > existing setting for cores with 2 FMA pipes, and use 4 for cores with 4
> > FMA pipes. This improves SPECFP2017 on
Wilco Dijkstra writes:
> Add a reassocation width for FMAs in per-CPU tuning structures. Keep the
> existing setting for cores with 2 FMA pipes, and use 4 for cores with 4
> FMA pipes. This improves SPECFP2017 on Neoverse V1 by ~1.5%.
>
> Passes regress/bootstrap, OK for commit?
>
> gcc/
>
Add a reassocation width for FMAs in per-CPU tuning structures. Keep the
existing setting for cores with 2 FMA pipes, and use 4 for cores with 4
FMA pipes. This improves SPECFP2017 on Neoverse V1 by ~1.5%.
Passes regress/bootstrap, OK for commit?
gcc/
PR 107413
*
