[FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

[Ganesh Ajjanagadde]

On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz <mfcc64 at gmail.com> wrote:
> On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>> On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer
>> <michael at niedermayer.cc> wrote:
>>> On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote:
>>>> On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>>> > From: Michael Niedermayer <michael at niedermayer.cc>
>>>> >
>>>> > This should fix the build failure of avf_showcqt.c
>>>> >
>>>> > An alternative solution would be to add a check for fmin/fmax to fate-source and
>>>> > then to replace them by FFMIN/FFMAX, i can do that if preferred?
>>>> >
>>>> > Untested due to lack of a affected platform
>>>>
>>>> I recall some interest on my end to get fmin, fmax etc for different
>>>> reasons, and it was remarked that commit
>>>> 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary
>>>> seems to be that getting it to work on all platforms is not so simple.
>>>
>>> :/
>>> ill replace the problematic ones by FFMIN/MAX for now so the build
>>> failure on the affected msvc platforms is fixed
>>> tieing a build fix to this complexity would be unwise
>>>
>>>
>>>> I am definitely interested in getting it to work in order to replace
>>>> FFMAX/FFMIN for floating point in especially libavfilter. This will
>>>> allow better nan signalling at a slight performance cost.
>>>
>>> would that performance cost affect all systems or just ones not
>>> having fmin/fmax ?
>>> i think affecting all systems would be bad
>>
>> A correct fmin and fmax will be slower than FFMIN/FFMAX, simply
>> because they do NaN handling. How much slower, I have not tested. Also
>> note that flags may be passed to the compiler to ignore NaN's,
>> something which can possibly be done locally if desired. However, I
>> view FFMAX/FFMIN as the cleaner solution if NaN signalling/propagation
>> is not an issue, so I may not pursue this.
>>
>
> Common problem with FFMIN/FFMAX (and other macros that evaluates
> arguments more than once):
> FFMAX(a, myfunc(b))
> will call myfunc twice (OK compiler may optimize it and call myfunc once)
> and often people don't care about it.

That goes without saying, but sometimes compiler can't optimize due to
sequence point stuff. This is why the macro should be used cautiously.
However, FFmpeg devs are generally cautious about these things so I no
longer press this that hard. The real technical benefit (if any) is
the different NaN handling as noted above.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel