[FFmpeg-devel] gcc 2.95.3 support plan

[Ivan Kalvachev]

On 2/11/09, Fran?ois Revol <revol at free.fr> wrote:
>> Mike Melanson wrote:
>> > Hi,
>> >
>> > r17059 (ASM optimizations by Loren) broke compilation on x86_32/gcc
>> > 2.95.3:
>> >
>> > /home/fate/fate32/source/libavcodec/x86/dsputil_mmx.c: In function
>> > `add_hfyu_median_prediction_cmov':
>> > /home/fate/fate32/source/libavcodec/x86/dsputil_mmx.c:580: more
>> > than 10
>> > operands in `asm'
>> >
>> > I propose several options:
>> >
>> > 1. declare the configuration unsupported as of now and I remove the
>> > configuration from FATE
>> >
>> > 2. declare the configuration supported, but without optimizations,
>> > and
>> > I'll adjust FATE to build it with '--disable-mmx' (I just checked
>> > and
>> > this builds and passes regressions)
>> >
>> > 3. revert 17059 for now, declare that the upcoming release is the
>> > last
>> > one that will support the full configuration, and then re-apply
>> > Loren's
>> > optimizations; then declare either 1 or 2
>> >
>> > Which shall it be?
>> >
>> >
>>
>> 4. Add some ifdefs to disable the code on 2.95.3.
>>
>> I'm in favor of this solution as I actually use this target.
>
> For what it's worth I've long stopped trying to build with mmx in BeOS
> anyway... I know some ppl use gcc4 but it's really painful.

5. Revert the function and cokacola-board Loren until he writes a proper one.

It is absolutely safe to remove that function as it have never worked correctly
in the first place. At the moment it is used when MMX_EXT is not
present but 3DNow is. That condition is true only on K6-2/3 processors
and they for sure do not have cmov instruction. (Table.9 AMD Processor
Recognition 20734.pdf).


I think that writing an mmx version would be far more beneficial than cmov one.