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

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Martin Storsjö
> Sent: Sunday, June 12, 2022 10:58 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Cc: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
> Subject: Re: [FFmpeg-devel] [PATCH] all: Replace if (ARCH_FOO) checks
> by #if ARCH_FOO
> 
> On Sun, 12 Jun 2022, Martin Storsjö wrote:
> 
> > On Sun, 12 Jun 2022, Soft Works wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >>> Andreas Rheinhardt
> >>> Sent: Sunday, June 12, 2022 7:28 AM
> >>> To: ffmpeg-devel@ffmpeg.org
> >>> Cc: Andreas Rheinhardt <andreas.rheinhardt@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@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.
> >
> > Can you qualify this statement? This does not match my
> understanding.

Now I remember: it was recently when all those ARCH_LOONGARCH** changes
were made. I needed to switch back and forth between multiple working 
branches at different baseline levels. I had compile errors 
(not linking errors) quite often; probably it was due to me not 
adding/removing loong related code files on each branch switch.
Takeaway was that I wouldn't have had the trouble when those code parts
would have been guarded by #if or #ifdef


> ... because eliminating unused code (for e.g. debug printouts) using
> DCE
> instead of ifdefs has got the advantage that the skipped code still
> is
> syntax checked (so it doesn't bitrot), compared to in ifdefs where it
> can
> easily become stale.

What I meant is that you have control over code parts being active or 
inactive. For example, I do VAAPI or Android stuff primarily in VS.
It doesn't actually compile, but when changing the macros in config.h, 
I get nice pre-compilation and diagnostics before actually compiling on/
for the target platform. 
Also, code navigation and reference searches begin to work instantly
after changing the config macros because even the inactive code is parsed
and results are being included once the condition is changed.

Sorry for being at bit vague before..

softworkz






_______________________________________________
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".