On 06/26/2012 04:04 PM, Jason Garrett-Glaser wrote: > On Tue, Jun 26, 2012 at 1:01 PM, Justin Ruggles > <[email protected]> wrote: >> 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: > > Atoms don't have OOE at all, so they aren't a very good test for > changes like that.
What x86 does then? -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
