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

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

On Tue Apr 21, 2026 at 9:48 AM PDT, Eduard Zingerman wrote:
> On Tue, 2026-04-21 at 09:23 -0700, Alexei Starovoitov wrote:
>> On Tue Apr 21, 2026 at 3:28 AM PDT, Eduard Zingerman wrote:
>> >  
>> >  static void scalar32_min_max_udiv(struct bpf_reg_state *dst_reg,
>> > @@ -14119,7 +13548,6 @@ static void scalar32_min_max_udiv(struct bpf_reg_state *dst_reg,
>> >  			 reg_u32_max(dst_reg) / src_val);
>> >  
>> >  	/* Reset other ranges/tnum to unbounded/unknown. */
>> > -	reg_set_srange32(dst_reg, S32_MIN, S32_MAX);
>> >  	reset_reg64_and_tnum(dst_reg);
>> >  }
>> 
>> div/mod don't need special cnum_div ?
>
> There is an algorithm for that in the paper, but it turned out to be
> unnecessary for our verification purposes. At-least for the corpora of
> programs I used for testing. I didn't try the "dumb" multiplication
> version, expect it to fail for cross sign-domains cases.
>
>> 
>> > @@ -15861,38 +15209,54 @@ static void regs_refine_cond_op(struct bpf_reg_state *reg1, struct bpf_reg_state
>> >  		break;
>> >  	case BPF_JLE:
>> >  		if (is_jmp32) {
>> > -			reg_set_urange32(reg1, reg_u32_min(reg1), min(reg_u32_max(reg1), reg_u32_max(reg2)));
>> > -			reg_set_urange32(reg2, max(reg_u32_min(reg1), reg_u32_min(reg2)), reg_u32_max(reg2));
>> > +			lo32 = cnum32_from_urange(0, reg_u32_max(reg2));
>> > +			hi32 = cnum32_from_urange(reg_u32_min(reg1), U32_MAX);
>> > +			reg1->r32 = cnum32_intersect(reg1->r32, lo32);
>> > +			reg2->r32 = cnum32_intersect(reg2->r32, hi32);
>> >  		} else {
>> > -			reg_set_urange64(reg1, reg_umin(reg1), min(reg_umax(reg1), reg_umax(reg2)));
>> > -			reg_set_urange64(reg2, max(reg_umin(reg1), reg_umin(reg2)), reg_umax(reg2));
>> > +			lo = cnum64_from_urange(0, reg_umax(reg2));
>> > +			hi = cnum64_from_urange(reg_umin(reg1), U64_MAX);
>> > +			reg1->r64 = cnum64_intersect(reg1->r64, lo);
>> > +			reg2->r64 = cnum64_intersect(reg2->r64, hi);
>> 
>> Maybe a helper like:
>> cnum64_intersect_with_range(&reg1->r64, 0, reg_umax(reg2));
>> ?
>> 
>> Also I found only one case:
>> dst_reg->r64 = cnum64_intersect(u, s);
>> 
>> all others dst and src are the same.
>> So maybe:
>> cnum64_intersect(&dst_reg->r64, ..);
>> as a main helper and __cnum64_intersect(r->r64, ...) as a subhelper that returns cnum?
>
> Are you concerned about machine code inefficiencies from struct cnum
> being passed around as a temporary/parameter/return value? Since cnum
> functions are in a separate compilation unit, I'd guess there won't be
> much optimization outside LTO builds.
> Or do you just like the &r->r64 notation more?

The latter. Just less verbose and less error prone.
While looking at the diff I kept comparing both sides of '='.
Just unnecessary mental overhead.