On 06/26/2012 01:51 AM, Jason Garrett-Glaser wrote:
> On Mon, Jun 25, 2012 at 9:27 PM, Justin Ruggles
> <[email protected]> wrote:
>> On 06/25/2012 05:23 PM, Jason Garrett-Glaser wrote:
>>>> +cglobal conv_s16_to_fltp_2ch, 3,4,5, dst0, src, len, dst1
>>>> + lea lenq, [4*lend]
>>>> + mov dst1q, [dst0q+gprsize]
>>>> + mov dst0q, [dst0q ]
>>>> + add srcq, lenq
>>>> + add dst0q, lenq
>>>> + add dst1q, lenq
>>>> + neg lenq
>>>> + mova m4, [pf_s16_inv_scale]
>>>> + ALIGN 16
>>>> +.loop:
>>>> +%if cpuflag(sse4)
>>>> + pmovsxwd m0, [srcq+lenq ]
>>>> + pmovsxwd m1, [srcq+lenq+mmsize/2]
>>>> +%else
>>>> + mova m1, [srcq+lenq]
>>>> + punpcklwd m0, m1
>>>> + punpckhwd m1, m1
>>>
>>> This definitely looks wrong; m0 hasn't been set to anything. Did you
>>> test this? Like in another email, I'd suggest using a macro to
>>> abstract this.
>>
>> Yeah, it works. I did make a macro for it, I just forgot to use it here...
>>
>>>> + psrad m0, 16
>>>> + psrad m1, 16
>>
>> The uninitialized parts get shifted away there.
>
> It still creates a false dependency that prevents the processor from
> OOEing the loop, though, so it should be avoided.
What would you suggest?
I tried zeroing the 2nd dst register and it didn't make any real
difference on atom. Here is the current macro:
%macro S16_TO_S32_SX 2 ; src/low dst, high dst
%if cpuflag(sse4)
pmovsxwd m%2, m%1
psrldq m%1, 8
pmovsxwd m%1, m%1
SWAP %1, %2
%else
punpckhwd m%2, m%1
punpcklwd m%1, m%1
psrad m%2, 16
psrad m%1, 16
%endif
%endmacro
-Justin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
