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. Jason _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
