Re: [PATCH RFC bpf-next 0/4] bpf: replace min/max fields with struct cnum{32,64}

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue Apr 21, 2026 at 3:28 AM PDT, Eduard Zingerman wrote:
>
> Debug metrics
> =============
>
> To understand the practical impact of the precision trade-offs,
> two debug counters were added (here [3]):
>
> - isec_overapprox: counts how many times cnum_intersect() in
>   conditional branch refinement had to collapse two disjoint arcs into
>   one, losing precision that the signed/unsigned pair could represent.
>
> - crossing_poles: counts how many times an ALU operation produces a
>   cnum that crosses both the unsigned (0/U_MAX) and signed
>   (S_MAX/S_MIN) boundaries simultaneously. Such cnums cannot be
>   represented as a pair of signed and unsigned ranges.
>
> Across 6683 programs:
> - crossing_poles fires 551K times for 21% of programs.
> - isec_overapprox fires 119K times for 12% of programs,

so cnums win 551k times and lose 119k ?

>   most programs have only 1-5 hits. The bulk comes from a few large
>   sched_ext and profiling programs.

and most losses are in sched_ext, yet overall it's a win:

 scx_rusty.bpf.o  rusty_enqueue         39842      22053  -17789 (-44.65%)
 scx_rusty.bpf.o  rusty_stopping        37738      19949  -17789 (-47.14%)
 scx_wd40.bpf.o   wd40_stopping         37729      19880  -17849 (-47.31%)

> - 801 programs have crossing_poles > 0 with isec_overapprox = 0.
> - 202 programs have isec_overapprox > 0 with crossing_poles = 0.

similar wins vs losses story ?

I think even without wins we have to adopt cnum-s mainly for memory
savings. Once we move to model where do_check_insn() is a transfer
function the memory savings will become more important.