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

From: Kacper Michajlow <kasper93-at-gmail.com@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/2] Replace FFMIN/FFMAX by type specific macros
Date: Sat, 28 Jun 2025 16:35:17 +0200
Message-ID: <CABPLASQ7EdQXW5TzO3uH5vrDzq3FyJ7DvM-RUenSW2tO__cXSA@mail.gmail.com> (raw)
In-Reply-To: <CA8E0C4A-8931-4624-B85A-F06F2D16BE04@remlab.net>

On Mon, 2 Jun 2025 at 17:06, Rémi Denis-Courmont <remi@remlab.net> wrote:
>
>
>
> Le 31 mai 2025 20:40:40 GMT+03:00, Marton Balint <cus@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? 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)

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.

- Kacper

> And that was Debian, not some obscure compiler build of mine. As much as I generally would argue that compiler bugs aren't our problem, well...
>
> >And if we are introducing something new, do we really want to stick to MIN/MAX macros which possibly evaluate their argument multiple times? It was always an issue, so I would love to see us moving away from it.
>
> We can use static inlines to avoid that, but they won't work in const context. I don't think that there is a solution that would be portable, constant and expansion-safe all at the same time.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".