[FFmpeg-devel] Moving if(constant expression) to preprocessor?

[Axel Holzinger]

M?ns Rullg?rd wrote:
> "Axel Holzinger" <aholzinger at gmx.de> writes:
> 
> > M?ns Rullg?rd wrote:
> >> "Axel Holzinger" <aholzinger at gmx.de> writes:
> >> 
> >> > I want to compile witout optimisation.
> >> > Why shouldn't I?
> >> 
> >> Because without optimisation, the code will be unusably slow.
> >
> > Use the release build then. You get optimisation, which you 
> like and 
> > full speed. Let me have zero optimisation and easy debugging.
> 
> This reminds me of an old joke:
> 
> A man is walking down a dark country lane when he notices a 
> stranger standing beneath a lone lamp post, staring intently 
> at the ground as though searching for something.  He greets 
> the stranger and offers his assistance.
> 
> "I seem to have lost my keys, I think it was over there," the 
> stranger replies, indicating along the road.
> 
> "If you lost them there, then why are you searching here?"
> 
> "There is a lamp here, so it is easier to see."

I tried hard, rally, but I don't see the parallel.

> >> > What is the benefit of optimisation in a debug build?
> >> 
> >> What is the benefit of debugging code you do not intend to use?
> >
> > To understand the architecture.
> > To understand why a special function call fails.
> > To understand why another works correct.
> >
> > Need more?
> 
> I don't see how doing any of the above is related to 
> optimisation being enabled or not.

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?

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.

> > Every now and then in FFmpeg user or libav user I read "Look at
the 
> > 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
optimised 
> > away local variables, loops, etc.
> 
> printf is your friend.

Some debuggers are your frient sometimes (okay, maybe not gdb ;-)

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.

> > And still I don't see what is the advantage of an optimised debug 
> > build. What the hell is the debug build good for anyhow then?
> 
> A debug build has full symbol information, including line 
> numbers, which greatly simplifies the analysis of core dumps 
> and profiling data.

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.

> >> > Using a const expression in a runtime if is obfuscation
> >> 
> >> Code is obfuscated when it is not obvious at a glance what it
does.
> >> If you find it hard to understand what
> >>    if (CONFIG_FOO) do_something();
> >> does, you should probably consider a career not involving 
> programming.
> >
> > 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?

> >> > and besides it's plain bad style.
> >> 
> >> Matter of opinion.  You have made yours clear, as have we 
> ours.  We 
> >> happen be the ones making the rules here, not you.
> >
> > Halleluja. God has spoken.
> 
> Would like that inscribed on stone tablets?

Sure, send them by email :-)

> >> > Relying on dead code elimination for making a build 
> succeed is a hack.
> >> 
> >> Is relying on the optimisation to make the code fast enough also
a 
> >> hack?
> >
> > No.
> 
> OK... so how are we to know which optimisations are a "hack" 
> and which ones are kosher?

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.

Axel