[FFmpeg-devel] [PATCH] avfilter/vf_fspp.c: make the filter compile with latest LLVM
Thierry Foucu
tfoucu at gmail.com
Thu Oct 31 20:16:55 CET 2013
On Thu, Oct 31, 2013 at 12:09 PM, Reimar Döffinger <Reimar.Doeffinger at gmx.de
> wrote:
> On Thu, Oct 31, 2013 at 11:53:22AM -0700, Thierry Foucu wrote:
> > Make the vf_fspp code not use the incorrectly documented and essentially
> > compiler-internal inline assembly constraint "o" which simply does not
> work
> > the way it was being used. Instead, pass explicit memory operands out of
> the
> > array of temporaries. The compiler is smart enough to build them with
> > immediate offsets of a common register address.
> >
> > In the process, remove 2 unused 8-byte temporaries from two functions in
> this
> > filter. Doing this saves 16 bytes of stack space, and in row_idct_mmx
> allows
> > the use of simpler addressing modes (no offset from %rsp) which saves 3
> bytes
> > of encoded instruction stream.
> >
> > Otherwise, this produces *exactly* the same assembly as the previous
> version,
> > but can be assembled by LLVM as well as GCC.
>
> Which gcc versions did you try with?
>
I tried with only one version of gcc "version 4.6.3"
For LLVM, i used :
clang version 3.4 (trunk 192869)
Without this change, clang reports this type of errors:
libavfilter/libmpcodecs/vf_fspp.c:1975:42: error: unknown token in expression
"paddw %%mm4, %%mm1 \n\t"
^
<inline asm>:22:18: note: instantiated into assembly here
movq %mm5, 0*8+(%r12)
^
libavfilter/libmpcodecs/vf_fspp.c:1978:42: error: unknown token in expression
"punpcklbw %%mm7, %%mm3 \n\t"
^
<inline asm>:24:18: note: instantiated into assembly here
movq %mm6, 1*8+(%r12)
I am fairly convinced the way you propose is the way it was originally
> implemented, but regularly failed to compile due to running out of
> registers on some gcc version.
> Keep in mind that gcc 4.1 is still in very regular use...
>
Sorry.. I did not know the history of this file.
We are trying to make it compile with clang so we can use their Address
Sanitizer.
but based on this thread
http://gcc.gnu.org/ml/gcc-help/2011-04/msg00518.html
it seems that the use of the "o" constraint was never really working
correctly.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
More information about the ffmpeg-devel
mailing list