On Sat, 28 Jun 2025 at 20:57, Rémi Denis-Courmont <r...@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 <r...@remlab.net> wrote: > > > Le 31 mai 2025 20:40:40 GMT+03:00, Marton Balint <c...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
