On 4/16/2017 8:57 AM, Matt Oliver wrote:
On 14 April 2017 at 08:05, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
On Fri, Apr 14, 2017 at 12:00 AM, Ronald S. Bultje <rsbul...@gmail.com>
wrote:
Hi Aaron,
On Thu, Apr 13, 2017 at 4:47 PM, Aaron Levinson <alevi...@aracnet.com>
wrote:
#if ARCH_AARCH64
if (ARCH_AARCH64)
return ff_get_cpu_flags_aarch64();
#endif
If you add #if, at least replace the if with it. #if + if is redundant.
Such a script could be reviewed and checked into the source base, then
applied to the source base, and possibly reused in the future as
necessary.
Why not use the script as a preprocessor during compilation? We did that
for pre-2013 MSVC compilation and that worked """fine""".
Or why not ask Microsoft to add a CLI option to cl.exe for enabling DCE
but
otherwise disabling optimizations? All other compilers seem capable of
this, so it's odd to see that big Microsoft is incompetent whereas a
bunch
of opensource hippies could do the same 10+ yrs ago.
Its not a MSVC-exclusive problem. Many compilers don't perform DCE in
full debug builds, which are as such not possible with ffmpeg, making
debuging sometimes a bit annoying when a bunch of variables are
optimized out and stuff gets inlined.
Unfortunately writing a script is a rather complex task as there are many
DCE blocks that are actually generated by macro expansion and various
pre-processor trickery (swresample is full of this sort of stuff). Combine
that with DCE blocks being nested within each other and it becomes a rather
complex task to find them all. Much more complex than what a simple regex
script can handle.
If people object to changing the current code base then the only solution
would be a program/script that can generate some empty definitions for all
the functions/variables that are used in DCE blocks so as to avoid the
errors about them not existing. These empty definitions would have to be
maintained in a set of external files or generated at compile time.
There are actually a considerable number of missing funcs/vars used in DCE
blocks. As an example i have attached a list of empty funcs/vars that I
have been able to programmatically detect (there are a lot! and i may have
missed some).
I like using this approach, but I think such files should only be added
to the build if --disable-optimizations is passed into configure. I
think that's the sort of approach that most people could get behind
since it won't affect the regular build. I think it is okay if these .c
files aren't perfect from the start, and while it would be nice if
people that add new functions (or change existing function definitions)
to arch (or similar) were to make appropriate changes to these files, if
they don't, that's okay too. There are likely a limited number of
people that would choose to employ --disable-optimizations, and it is
not a big deal to add a function or two to these files as they crop up
and submit a patch for the changes.
Aaron
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
