On Tue, 12 May 2026 11:58:30 -0700 Chia-I Wu <[email protected]> wrote:
> On Tue, May 12, 2026 at 4:54 AM Boris Brezillon > <[email protected]> wrote: > > > > Now that panthor_irq contains the iomem region, there's no real need > > for the macro-based panthor_irq helper generation logic. We can just > > provide inline helpers that do the same and let the compiler optimize > > indirect function calls. The only extra annoyance is the fact we have > > to open-code the panthor_xxx_irq_threaded_handler() implementation, but > > those are single-line functions, so it's acceptable. > We might want to __always_inline panthor_irq_default_threaded_handler. Yep, I can flag it __always_inline, but I'd be surprised if the compiler wasn't always inlining anyway, unless you use more exotic optimization options, like -Os (not even sure that would be the case with -Os, I didn't check), at which point it becomes a user decision, and not inlining is probably fine. > For the rest, do we want to un-inline them? Most of them are super trivial, and I think there's benefit in having them inlined. Again, because it's not __always_inline, the compiler is still free to unline, but at least we wouldn't resort to LTO for this sort of inlining optimization. So I'm still tempted to keep it as static inline helpers defined in the header file, unless you a strong reason to think this is a bad idea.
