Re: [PATCH] gpu: nova-core: bitfield: use &mut self setters instead of builder pattern

[Joel Fernandes <joelagnelf@nvidia.com>]

On 12/31/2025 7:46 PM, John Hubbard wrote:
> On 12/31/25 4:15 PM, Joel Fernandes wrote:
>>> On Dec 31, 2025, at 5:47 PM, John Hubbard <jhubbard@nvidia.com> wrote:
>>>
>>> On 12/31/25 2:33 PM, Timur Tabi wrote:
>>>>> On Wed, 2025-12-31 at 13:47 -0800, John Hubbard wrote:
>>>>> The builder-pattern setters (self -> Self) enabled method chaining like:
>>>>>
>>>>>     reg.set_foo(x).set_sec(y).write(bar);
>>>>>
>>>>> This made separate operations appear as a single expression, obscuring
>>>>> that each setter is a distinct mutation. 
>>>>
>>>> So you're concerned about the fact that the compiler is not merging the set_foo(x) and the
>>>> set_sec(y) into a single read-modify-write?
>>>
>>> No, I don't care about that aspect.
>>>
>>>>
>>>>> These setters are infallible,
>>>>> so the chaining provides no error-propagation benefit—it just obscures
>>>>> what are simple, independent assignments.
>>>>>
>>>>> Change the bitfield!() macro to generate `&mut self` setters, so each
>>>>> operation is a distinct statement:
>>>>>
>>>>>     reg.set_foo(x);
>>>>>     reg.set_sec(y);
>>>>>     reg.write(bar);
>>>>
>>>> Are you sure about this?  It just seems like you're throwing out a neat little feature of Rust and
>>>> replacing it with something that's very C-like.  This breaks compatible with all users of the regs
>>>> macros.  Seems really disruptive for what seems to me like a cosmetic change.
>>>>
>>>
>>> It's only a neat feature if it *does* something. In this case, it *looks*
>>> like a neat Rust feature, but under the covers it really is just handing
>>> around copies unnecessarily, when really, it *is* doing the C-like thing
>>> in the end.
>>>
>>> I object to the fake Rust-ness that's being done here. It's like putting
>>> hubcabs on a car.
>>
>> But IMO there is only one operation here, the IO write. The setter is just mutations. Builder pattern chaining is idiomatic to Rust.
>>
>> I would not call it fake Rustness since it is Rustness in the Rust language. Afair, similar arguments were made before and conclusion was, well, this is Rust.
> 
> There is nothing about doing sequential .set_foo() calls that goes against
> Rust idioms.

Huh, I just meant we should "Ok" with and inclined to be using Rust idioms even
though they may seem unfamiliar at first.

> 
> But this really is fake chaining, because there are no Results involved.
> It's not buying us anything except a bit of indirection and cognitive
> load for the reader.

Chaining is not really only about error propagation. Builder pattern can be used
for other cases too, like passing a setter chained expression to a function
argument for better clarity, I was planning to do that for the sequencer for
instance since there's a lot of parameters passed to it.

But in this case, I am actually absolutely opposed against this, it makes the
API hard to use because now how do you differentiate between an IO function call
versus something that just mutates memory? Is set() an IO or write()?

     reg.set_foo(x);   // no IO
     reg.set_sec(y);
     reg.write(bar);   // IO.

So no thank you, I quite dislike it. :)

Instead with chaining, we can just rely on the last part of the chain concluding
in a write() with the intermediaries just mutating memory.

Further, your suggestion could also make it easier to introduce bugs?

     reg.set_foo(x);
     reg.write(bar);
     reg.set_sec(y);

While this is also possible to mess up with the register macro, it is much
harder to do with chaining since there is no opportunity to interleave a write()
incorrectly.

>> Regarding the copies, I am intrigued - have you verified that the code generation actually results in copies? I would be surprised if the compiler did not optimize.
> 
> 
> No no, I just mean conceptually using Copy instead of a mutable Self.
> 

Conceptually, but the compiler would not do any copies through the setter chain
was my point though. Note that all setters are #[inline(always)], the compiler
should optimize chained calls to simple register bit manipulation. If that is
not happening, we should definitely look more into it.

thanks,

 - Joel