On Tue, 2011-04-26 at 10:42 +0100, Måns Rullgård wrote: > Uoti Urpala <[email protected]> writes: > > On Sun, 2011-04-24 at 07:05 -0400, Ronald S. Bultje wrote: > >> On Sun, Apr 24, 2011 at 2:06 AM, Uoti Urpala <[email protected]> > >> wrote: > >> > The current generic C implementation, which is always used when the > >> > public header is included from other programs (either directly or > >> > through intreadwrite.h) compiles to a mess like this (gcc-4.6 on AMD64):
> >> > The builtin function produces just a bswap. > >> > > >> > If the built-in functions behave particularly badly on some less common > >> > architecture then additional checks to exclude those could be > >> > beneficial; but in any case this should be enabled at least for > >> > amd64/x86. > >> > >> Why not simply start distributing avconfig.h and also distribute > >> arch-specific installed headers? > > > > Some of the arch-specific headers use config.h definitions that are only > > valid for the Libav build environment and may not apply to the > > environment where the public header is included. Perhaps some of the > > architecture-specific optimizations could be picked to be exported, but > > that would get more complex than this patch. > > Yes, that opens a large can of worms. Using the builtins under > appropriate ifdefs is fine of course, provided some caution is used. > See http://hardwarebug.org/2010/01/14/beware-the-builtins/ for details. If you want to add special cases for some known bad architecture / GCC version combinations, or only limit it to known good ones, then please do that. In any case this should be enabled for at least amd64/x86, and any special casing for rarer architectures has to be done by people who work with them (so the patch should not get stuck due to any "doesn't have optimizations for all possible arches" reason). _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
