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

[Eduard Zingerman <eddyz87@gmail.com>]

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?