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

[Vineet Gupta <vineet.gupta@linux.dev>]

On 9/21/26 11:25 PM, Alexei Starovoitov wrote:
> On Mon Sep 21, 2026 at 10:17 PM UTC, Eduard Zingerman wrote:
>> On Mon, 2026-09-21 at 21:55 +0000, Alexei Starovoitov wrote:
>>> On Mon Sep 21, 2026 at 7:44 PM UTC, Eduard Zingerman wrote:
>>>>>>>> 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.
>>> Ok, so we're argeeing that it's not 'full' in your above definition.
>>> Your enum id_link_kind needs a 4th category : apply-delta-to-lower-32bit-...
>>> and it's not bi-directional.
>> It's not really a category, it's just a direction in a sync function:
>> - if known_reg is 'full' -> sync to sext/zext register recovers lower
>>    32-bits and infers upper
>> - if known_reg is sext/zext -> sync to 'full' register recovers only
>>    lower 32-bits and keeps upper untouched (counting on cross-domain
>>    bounds sync logic).
>> - 'full' -> 'full' and 'sext/zext' -> 'sext/zext' syncs are trivial.
>>
>>> rX = ...
>>> wY = wX
>>> wY += 5
>>> if wY == 10
>>> here can apply -5 to lower 32-bit of rX only.
>>>
>>> rX = ...
>>> wY = wX
>>> wY += 5
>>> if rX == 10
>>> here can apply +5 to lower 32-bit of wY _and_ do zero extend into full rY.
>>>
>>> I don't see a value of 'zext' kind alone that doesn't do 'add delta'.
>> Exactly, that's why I suggest this as a completely orthogonal encoding.
>> Effectively for an abstract scalar value X it would encode whether
>> the particular register is:
>> - X + delta
>> - zext(X + delta)
>> - sext(X + delta)
> ahh. it wasn't clear to me that 'zext' you're proposing does '+ delta'.
> Now I see that your zext is the same as apply-delta-to-lower-32bit-and-zext
> as I was talking about all along.

So to close the loop on this v3 will support the above three forms: 
add_const:2 and subreg_ext:1merge into one {none,

And just to recap, we will be adding two features:
  - adding the sext with delta
  - reverse syncing of low 32 bits

Thx,
-Vineet