On Tuesday, June 26, 2012, Justin Ruggles <[email protected]> wrote: > 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?
The first OOE x86 was the Pentium Pro, and. I think the Atom is the only one that doesn't? -- Sean McG.
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
