[FFmpeg-devel] [PATCH 1/2] Replace FFMIN/FFMAX by type specific macros

[Kacper Michajlow]

On Sat, 28 Jun 2025 at 20:57, Rémi Denis-Courmont <remi at remlab.net> wrote:
>
> Le lauantaina 28. kesäkuuta 2025, 17.35.17 Itä-Euroopan kesäaika Kacper
> Michajlow a écrit :
> > On Mon, 2 Jun 2025 at 17:06, Rémi Denis-Courmont <remi at remlab.net> wrote:
> > > Le 31 mai 2025 20:40:40 GMT+03:00, Marton Balint <cus at passwd.hu> a écrit :
> > > >On Sat, 31 May 2025, Michael Niedermayer wrote:
> > > >> This allows adjusting them to exactly match whatever is fastest on
> > > >> a given CPU for each type.
> > > >
> > > >Did you use some tool to make this patch, or it was just manual work?
> > > >
> > > >Can't you use C11 generics to make this somewhat automatic?
> > >
> > > So I tried to do exactly that, but you need multiple levels of generics.
> > > In the end, either the compiler crashed or my entire build system crashed
> > > because the compiler consumed too much memory.
> > Could you elaborate on the problem?
>
> No, I can't. I had neither the skills nor the time to debug my distro's C
> compiler.

No, I mean could you elaborate on the challenges why you need 4 nested
generics that ultimately don't compile?

> > I too think that _Generic is the
> > way to go here, instead error-prone manual dispatch of the MIN/MAX
> > functions. Also with _Generic we can substitute with an inline
> > function to fix double evaluation issues. (and whole patch would be
> > few lines instead of changing whole source tree)
>
> This is very difficult because FFMIN/FFMAX are also used for pointer
> comparisons. The float evaluations (with fmaxf/fminf and co) are invalid and
> will not compile, if the operand types are pointer types. Keep in mind that
> even not-selected cases of _Generic must compile.
>
> IIRC, I ended up with 4 levels of nested _Generic macros.

Yeah, why?

> > If you let us help you fix the problem you were facing, I think we can
> > arrive at a good solution for the problem here.
>
> Even if you can debug GCC, it'll be a decade or so before we can rely on the
> hypothetical future fixed version, so I very much doubt it.

I was thinking about fixing the code first, not the GCC itself.

I did a quick test myself, with specialization for all
integer/floating point types and default case for "the rest" which in
our case are all pointer comparisons which are dispatched to void*
comparison, which also makes sure that we compare pointers only. This
was with one _Generic.

I feel like using FFMAX for float/double/integers is more intuitive
and even if for some reason pointers are not fixable, we can have
separate MAX for pointers.

- Kacper