[FFmpeg-devel] [PATCH] all: Replace if (ARCH_FOO) checks by #if ARCH_FOO

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Hendrik Leppkes
> Sent: Sunday, June 12, 2022 11:09 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] all: Replace if (ARCH_FOO) checks
> by #if ARCH_FOO
> 
> On Sun, Jun 12, 2022 at 10:17 AM Soft Works <softworkz at hotmail.com>
> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Andreas Rheinhardt
> > > Sent: Sunday, June 12, 2022 7:28 AM
> > > To: ffmpeg-devel at ffmpeg.org
> > > Cc: Andreas Rheinhardt <andreas.rheinhardt at outlook.com>
> > > Subject: [FFmpeg-devel] [PATCH] all: Replace if (ARCH_FOO) checks
> by
> > > #if ARCH_FOO
> > >
> > > This is more spec-compliant because it does not rely
> > > on dead-code elimination by the compiler. Especially
> > > MSVC has problems with this, as can be seen in
> > > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296373.html
> > > or
> > > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/297022.html
> > >
> > > This commit does not eliminate every instance where we rely
> > > on the dead code elimination: It only tackles branching to
> > > the initialization of arch-specific dsp code, not e.g. all
> > > uses of CONFIG_ and HAVE_ checks. But maybe it is already
> > > enough to compile FFmpeg with MSVC with whole-programm-
> optimizations
> > > enabled (if one does not disable too many components).
> > >
> > > Signed-off-by: Andreas Rheinhardt
> <andreas.rheinhardt at outlook.com>
> > > ---
> >
> > LGTM.
> >
> > It's not really a story as simple as "poor MSVC is unable
> > to perform dead-code-elimination". It is actually capable to do
> that,
> > but the ffmpeg code was not only requiring the compiler to
> eliminate
> > dead code, it actually required a compiler to ignore dead code
> blocks
> > even when those would contain invalid code that cannot be compiled
> > at all.
> 
> This is inaccurate. This code can compile just fine. It is linking
> that fails, because the functions are not generated, which would not
> be a problem if it is removed as part of DCE before the linking
> stage.

You are right. It was not 100% precise. Three cases that I tried mangle 
into a single statement:


1. Statement might not compile when macro is not defined, e.g.:

    if (ARCH_LOONGARCH64)
        ff_nlmeans_init_xxxx(dsp);

would fail to compile when ARCH_LOONGARCH64 is not defined (not 1 not 0), 
but it doesn't fail with 

#if ARCH_LOONGARCH64
....

2. Linking fails e.g. when there's not definition of the function 
   ff_nlmeans_init_xxxx()

3. There was another case where I got a compilation (not linking) error 
   with MSVC but not with GCC. It wasn't as simple as a syntax error.
   I'll post when I remember what it was.

Thanks,
sw