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

[Måns Rullgård]

"Ronald S. Bultje" <rsbultje at gmail.com> writes:

> 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

Where would these types be used?  It is not at all certain that all
places where this should be used on x86 should use the same type on
another system.

What's so hard about sign-extending where needed anyway?  It has to be
done _somewhere_, and I thought we all agreed gcc shouldn't be trusted
to do things properly.

-- 
M?ns Rullg?rd
mans at mansr.com