Re: [PATCH v3 0/3] ivopt: Changes regarding reg pressure cost.

On 7/29/2026 4:07 PM, Alfie Richards wrote:
> On 29/07/2026 15:01, Jovan Dmitrovic wrote:
>> Hello everyone,
>>
>> I have revised this patch series, after some careful consideration.
>> As 1/3 from v2 has merged (and not included in this series),
>> I have switched up the order of patches, so 1/3 in v3 is 3/3 from v2.
>> Other two patches are been a rework of 2/3 from v2, split into two 
>> parts.
>>
>> I've decided upon removing target_reg_cost from estimate
>> of register pressure, as it doesn't seem to benefit the overall
>> calculation (most likely because we cannot predict at this stage
>> how the moving between registers will occur).
>>
>> The third patch is just scaling of the spill cost done to be closer
>> to what target_spill_cost actually is (cost of loading+storing from
>> stack).
>>
>> Kind reminder for Alfie to run his benchmarks on ARM,
>> so that we have info if there is any change.
>
> Hi Jovan,
>
> Thank you for the reminder,
>
> These numbers are for both spec v6 and spec v8 on an aarch64 
> neoverse-v2 core at -mcpu=native -Ofast -flto=auto averaged over 3 runs.
>
> The statistically significant changes in number of cycles are:
>
> Spec v6
> - blender_r: +1.47%
> - fotonik3d_r: +1.73%
> - ompnetpp_r: +0.65%
> Overall: +0.20% cycles
>
> Spec v8
> - flightdm_r: +0.57%
> - omnetpp_r: -1.38%
> - gem5_r: -0.42%
> Overall: -0.08% cycles
>
> (this is compared to current trunk, which already has the first patch)
>
> From a brief visual analysis the perf data and code gen from fotonik, 
> the regression seems to come from a change in a hot loop.
> Before these changes there were no spills to the stack in the loop 
> body. Afterwards there seem to be quite a few.
> Otherwise code gen looks largely similar.
This data would seem to indicate this patch series is a regression on 
that design.  Given Richi has ACK'd the patches that leaves us in a bit 
of a bind.  Do we go forward knowing about the likely performance 
regression, do we further break down the performance testing to try and 
show that one patch (ideally the last) is the source of the regression, etc.

Looking for guidance from Richi, Jovan and Alfie here...

jeff