[FFmpeg-devel] [Ffmpeg-devel] [PATCH] detect support for 10 operands in configure

[Diego Biurrun]

On Sat, Feb 14, 2009 at 03:09:16AM +0100, Diego Biurrun wrote:
> On Fri, Feb 13, 2009 at 06:53:45PM +0000, Loren Merritt wrote:
> > On Fri, 13 Feb 2009, Diego Biurrun wrote:
> > > On Thu, Feb 12, 2009 at 07:13:24PM +0000, Loren Merritt wrote:
> > >>
> > >> Oops, I saw one of the asm blocks replaced and didn't notice the other
> > >> one.
> > >> However, it is not a question of HAVE_TEN_OPERANDS. That asm used only 5
> > >> operands, and the problem was that gcc<4 failed to find 5 registers for
> > >> them. (Because it doesn't know how to spill ebx or ebp, nor does it know
> > >> how to spill one operand to free up a temp register to compute another.)
> > >>
> > >> I could put fft_3dn under (HAVE_7REGS || GCC4).
> > >> I could write the loop part in inline asm, and put fft_3dn under HAVE_7REGS.
> > >> I could force-disable frame-pointer and pic on fft_3dn.
> > >> I could move the loop to yasm, which isn't all that different insofar as
> > >> it also ignores frame-pointer and pic.
> > >> Or I could laugh at x86 for having too few registers, and ignore it.
> > >
> > > Hmmm, I have no problem compiling either fft_3dn.c nor fft_3dn2.c with
> > > any gcc I tested: 2.95.4, 3.3, 3.4, 4.1...
> > 
> > Did you revert r5964 before testing? If so, I don't know what's up. I 
> > never reproduced the original bug after all, I only committed the kludge.
> 
> Ooops, I indeed forgot about that.  After putting r5962 of fft_3dn2.c in
> place I tried compiling with gcc 4.1, 3.4, 3.3 and 2.95.  After changing
> asm to __asm__ and adjusting the function declaratin in dsputil.h it
> compiles fine with gcc 4.1, 3.4 and 3.3.  Only 2.95 fails and outputs
> the following error message:
> 
> libavcodec/x86/fft_3dn2.c: In function `ff_imdct_calc_3dn2':
> libavcodec/x86/fft_3dn2.c:214: Invalid `asm' statement:
> libavcodec/x86/fft_3dn2.c:214: fixed or forbidden register 7 (sp) was spilled for class GENERAL_REGS.
> 
> I'm sure we could add a check for this to configure.

Loren, what do you think?

Also note that merging back the code from r5964 is nontrivial for me
since I know zilch about x86 asm while you can probably do it in two
minutes or so...

Diego