Re: [PATCH bpf-next 00/12] bpf: Support 16-byte return values in the R0:R2 register pair

[Eduard Zingerman <eddyz87@gmail.com>]

On Thu, 2026-07-09 at 23:00 -0700, Yonghong Song wrote:
> 
> 
> On 7/9/26 5:56 PM, Eduard Zingerman wrote:
> > > On Wed, 2026-07-08 at 13:09 -0700, Yonghong Song wrote:
> > A design question regarding to how this series handles local
> > functions:
> > - It relies on the BTF gate to decide if function returns multiple values.
> > - It also prohibits local functions from returning pointers as a part
> >    of an aggregate return.
> > 
> > I think this unnecessarily adds an additional discrepancy between how
> > the return values are handled. The practical experience shows that
> > existing differences between local and global functions are already a
> > constant source of pain and confusion.
> > 
> > I'd also argue that lifting the above limitations for local functions
> > would make the implementation somewhat simpler.
> > 
> > Therefore, I suggest to:
> > - forgo the BTF check for local functions;
> > - always copy r2 from callee to caller at EXIT
> 
> Not sure about this. If r2 is always copied from callee to caller, and
> interpreter still only supports return r0, then this will imply interpreter
> will never be used? I know interpreter will be eventually removed, but
> at this point, people still use interpreter?

We can detect this statically from compute_live_registers().
If any r2's are alive after a function call the jit_required flag can be set.

> > - forgo the scalar struct requirement for local function
> >    return types.
> 
> I think this is doable.
> 
> > 
> > Wdyt?