[FFmpeg-devel] Moving if(constant expression) to preprocessor?
Mon Sep 20 02:59:11 CEST 2010
On 09/20/2010 12:02 AM, Axel Holzinger wrote:
> I tried hard, rally, but I don't see the parallel.
> Because optimised code doesn't reflect anymore the original C code.
> Come on, why do you use -O1 and not -O3 if optimisation isn't an issue
> in debug builds?
you can use -g with -O3 and it remains helpful...
> This discussion is ridiculous. You are using -O1 to get help by the
> optimiser to throw away code that anyhow wouldn't work. This might be
> convenient, you don't have to write stubs. But it's still a hack.
and works quite fine with a LARGE number of compilers...
>>> Every now and then in FFmpeg user or libav user I read "Look at
>>> code". I want to look at the code while it does process my
>>> calls. So I want to debug and I don't want to be hindered by
>>> away local variables, loops, etc.
>> printf is your friend.
> Some debuggers are your friend sometimes (okay, maybe not gdb ;-)
gdb is wonderful.
> Come on, use printf, if you like, but don't use this as an argumnt for
> not supporting clean unoptimised debug builds. printf works also in
> release builds.
added value in using printf (just don't if you have to debug threaded code)
> Fair enough, so where do you draw the line here? Having one to one
> compiled assembler code fitting the C code also simplifies debugging
> (there's not only runtime critical issues). I still can't understand
> how you can weigh the cost of four additional super simple macros so
> heavy while having optimiser free debug builds so light. FFmpeg/libav
> is a framework, there might be a thousand different forms of using,
> developing with it, not only yours. How much something helps somebody
> might not always be clear to you. How much addtional macros cost is.
> And again, it's no hackish special case macros, it's totally generic
> straight forward macros.
Do try yourself. have fun spending few hours doing that, see how it
doesn't change anything, enjoy when it breaks.
>>>>> Using a const expression in a runtime if is obfuscation
>>>> Code is obfuscated when it is not obvious at a glance what it
>>>> If you find it hard to understand what
>>>> if (CONFIG_FOO) do_something();
>>>> does, you should probably consider a career not involving
>>> You are referring to how the code WORKS. That is indeed
>> obvious - and
>>> as well obvious with "AV_IF" instead of "if". I'm referring
>> to how the
>>> code BUILDS - and that is NOT obvious with "if" and the
>> dependency on
>>> dead code elimination. It's not even documented in the code.
>> It is non-obvious to most people how just about any construct
>> is turned into machine code, yet they have no trouble
>> understanding the source.
> And you think these people are getting help by optimised debug builds?
processed macros get lost once you build the code, then you have _quite_
a problem tracking what was what.
> That's not the point. It's not about optimisation. The hack is that a
> compiler feature - in this case dead code elimination - is relied on
> to make the build succeed. An optimisation does not - or should not -
> affect the meaning of the code. Here it does. That was my point.
all they do in a way or another...
More information about the ffmpeg-devel