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): >> > movq %rdi, %rdx >> > shrq $32, %rdx >> > movl %edx, %eax >> > sall $8, %edx >> > shrl $8, %eax >> > andl $-16711936, %edx >> > andl $16711935, %eax >> > orl %edx, %eax >> > movl %edi, %edx >> > sall $8, %edi >> > shrl $8, %edx >> > andl $-16711936, %edi >> > roll $16, %eax >> > andl $16711935, %edx >> > orl %edi, %edx >> > roll $16, %edx >> > salq $32, %rdx >> > orq %rdx, %rax >> > ret >> > 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. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
