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 10:16 -0700, Alexei Starovoitov wrote:
> 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.

Funny thing is, I find the explicit '=' style easier to read :)
Anyway, can change to &r->r64 if people like it more.