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 <[email protected]> > > > > > 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.
