[FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
mfcc64 at gmail.com
Tue Nov 3 11:06:47 CET 2015
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):
will call myfunc twice (OK compiler may optimize it and call myfunc once)
and often people don't care about it.
More information about the ffmpeg-devel