Re: [PATCH bpf-next v2 03/13] bpf: track low-32 scalar equality across zero-extending movs

[Eduard Zingerman]

On Mon, 2026-09-21 at 19:27 +0000, Alexei Starovoitov wrote:
> On Mon Sep 21, 2026 at 7:10 PM UTC, Eduard Zingerman wrote:
> > On Mon, 2026-09-21 at 18:59 +0000, Alexei Starovoitov wrote:
> > > On Mon Sep 21, 2026 at 5:28 PM UTC, Eduard Zingerman wrote:
> > > > On Wed, 2026-09-16 at 17:30 -0700, Alexei Starovoitov wrote:
> > > > > On Wed, Sep 16, 2026 at 5:08 PM Vineet Gupta <vineet.gupta@xxxxxxxxx> wrote:
> > > > > > 
> > > > > > It ended up with full testsuite run parity - after 4 incremental patches.
> > > > > > But the pattern of all those patches was adding some predicate /
> > > > > > special-casing to reg->add_const
> > > > > > 
> > > > > > hunk 1
> > > > > > 
> > > > > > -       if (src_reg->add_const)
> > > > > > +       if (src_reg->add_const && src_reg->delta)
> > > > > 
> > > > > why? It should not.
> > > > > My point is that zero is not special.
> > > > > It should be handled within the current framework.
> > > > > All these extra hunks are not correct.
> > > > > ADD_CONST_32 logic should work for delta == 0 just like
> > > > > it works for delta == 1.
> > > > 
> > > > After thinking about it some more, I agree that having an orthogonal
> > > > encoding would be nice. However, it appears that the split should be
> > > > somewhat different:
> > > > 
> > > >   struct bpf_reg_state {
> > > >     ...
> > > >     s32 delta;
> > > >     u32 id;
> > > >     enum id_link_kind { full, zext, sext } link_kind;
> > > >     ...
> > > >   }
> > > > 
> > > > Where:
> > > > - id == 0 => no id link
> > > > - full => all 64-bits of the register are identical to
> > > >           all 64-bits of a scalar value `id' (let's call it X).
> > > >           ∀ rA{.id == X, .link == full}, rB{X,full} => rA == rB
> > > > - zext => lower 32-bits of the register are identical to
> > > >           lower 32-bits of a scalar value X,
> > > >           upper 32-bits of the register are null.
> > > >           ∀ rA{.id == X, .link == ?}, rB{X,zext} => rA % 32 == rB % 32
> > > > - sext => lower 32-bits of the register are identical to
> > > >           lower 32-bits of a scalar value X,
> > > >           upper 32-bits of the register are either 0 or 1,
> > > >           depending on the bit 31 value.
> > > >           ∀ rA{.id == X, .link == ?}, rB{X,sext} => sext(rA % 32) == sext(rB % 32)
> > > 
> > > hmm.
> > > there is also 32-bit link with delta, right?
> > 
> > My point is that delta is independent of 32-bit/64-bit property.
> > `delta' can be used to propagate in both directions:
> > - full 64 bit -> 32 bit sign/zero-extened
> > - 32 bit sign/zero-extened -> full 64-bit
> 
> both? how ?
> I was under impression that in 32-bit domain delta is one way.
> rX = ...
> wY = wX
> wY += 5
> 
> if wY == 10
> We cannot do -5 to rX

Why?
It is still valid to transfer r32 and tnum_subreg knowledge from wY to rX.

  wY + 5 == rX % 32 + 5 => hence rX % 32 knowledge can be recovered.

If rX itself had some delta, e.g.:

  rX = ...
  rX += 7
  wY = wX
  wY += 5

Then it would still be possible:

  wY + 5 == (rX - 7) % 32 + 5 = rX % 32 - 2.

Again, in case of this direction, only lower 32-bits of the 'full'
register can be inferred.

> and we cannot use your above 'full' encoding for wY += 5.
> Currently we use BPF_ADD_CONST32 for wY += 5
> I don't see how 'full' can work.