[FFmpeg-cvslog] r24926 - trunk/libavcodec/x86/vp56dsp.asm

[Ronald S. Bultje]

Hi,

2010/9/6 M?ns Rullg?rd <mans at mansr.com>:
> Michael Niedermayer <michaelni at gmx.at> writes:
>> On Mon, Sep 06, 2010 at 09:15:35PM +0100, M?ns Rullg?rd wrote:
>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>> > On Thu, Aug 26, 2010 at 10:09:27AM -0400, Ronald S. Bultje wrote:
>>> >> On Wed, Aug 25, 2010 at 11:41 AM, mru <subversion at mplayerhq.hu> wrote:
>>> >> > Author: mru
>>> >> > Date: Wed Aug 25 17:41:11 2010
>>> >> > New Revision: 24926
>>> >> >
>>> >> > Log:
>>> >> > VP6: fix vp6_filter_diag4_mmx/sse on 64-bit
>>> >> >
>>> >> > The stride can be negative and must be sign extended before being
>>> >> > used in pointer arithmetic.
>>> >> >
>>> >> > Modified:
>>> >> > ? trunk/libavcodec/x86/vp56dsp.asm
>>> >> >
>>> >> > Modified: trunk/libavcodec/x86/vp56dsp.asm
>>> >> > ==============================================================================
>>> >> > --- trunk/libavcodec/x86/vp56dsp.asm ? ?Wed Aug 25 17:32:29 2010 ? ? ? ?(r24925)
>>> >> > +++ trunk/libavcodec/x86/vp56dsp.asm ? ?Wed Aug 25 17:41:11 2010 ? ? ? ?(r24926)
>>> >> > @@ -127,6 +127,9 @@ cglobal vp6_filter_diag4_%1, 5, 7, %2
>>> >> > ? ? sub ? ? ? ? rsp, 8*15
>>> >> > ? ? movq ? ? ? ? m6, [pw_64]
>>> >> > ?%endif
>>> >> > +%ifdef ARCH_X86_64
>>> >> > + ? ?movsxd ? ? ? r2, r2d
>>> >> > +%endif
>>> >>
>>> >> This "problem" is biting me in other places too, and I don't like this
>>> >> at all. Does anyone have opinions on best way forward from here?
>>> >>
>>> >> <crazy>
>>> >> How about making all SIMD-related int->long?
>>> >> </crazy>
>>> >
>>> > i previously said that all things used as array indexes should be 64bit on
>>> > x86-64 (that is unless something else is faster for a specific case)
>>> > we (ramiro maybe?) tried long somewhen for sws until it was found out that
>>> > windows has 32bit long on x86-64 IIRC
>>> > x86_reg is the correct thing to use but IIRC that lead to some ehm discussion
>>> > about using something that says x86 in generic code. Iam not sure what the
>>> > result was or if i just gave up in light of that "discussion".
>>> > of course it can be renamed ...
>>>
>>> That would be correct on x86. ?It would not be correct on various
>>> other systems. ?I'm afraid there is no one size fits all solution
>>> here.
>>
>> which systems?
>
> Well, let's see:
>
> - int is wrong on x86_64
> - long is wrong on win64, MIPS N32, and PPC64
> - ptrdiff_t (or intptr_t) is wrong on MIPS64 and some PPC64 ABIs
> - long long is out of the question
>
> Did I miss any candidates?

#ifdef ARCH_X86
typedef ptridx x86_reg;
#else
typedef ptridx int;
#endif

or in dsputil.h:
#ifndef ptridx_defined
typedef ptridx int;
#endif
and then in dsputil_mmx.h:
typedef ptridx x86_reg
#define ptridx_defined 1

Could probably be done cleaner, but as a general idea that might work
quite well.

Ronald