Hi,

On 06/09/2012 04:07 AM, Christophe Gisquet wrote:
> Hello,
> 
> 2012/6/9 Justin Ruggles <[email protected]>:
>>      * @param dst result vector
>> -     *            constraints: 16-byte aligned
>> +     *            constraints: 32-byte aligned
>>      * @param src input vector
>> -     *            constraints: 16-byte aligned
>> +     *            constraints: 32-byte aligned
>>      * @param mul scalar value
>>      * @param len length of vector
>> -     *            constraints: multiple of 4
>> +     *            constraints: multiple of 16
> 
> I know it has been so for very long, and it applies to much more code
> than this, but has it ever been discussed for this that doxygen has
> the \pre and \post "commands" corresponding to pre- and
> post-conditions? To me, those look like pre-conditions, but maybe it
> doesn't fit well with how one may want those conditions to look in the
> doxy doc.

How will it look in the doxy doc if we use @pre?

> Hi,
> 
> 2012/6/9 Justin Ruggles <[email protected]>:
>> +%if UNIX64
>> +cglobal vector_fmac_scalar, 3,3,3, dst, src, len
>> +%else
>> +cglobal vector_fmac_scalar, 4,4,3, dst, src, mul, len
>> +%endif
> I already forgot how I had dealt with x86-64 calling convention
> myself, but shouldn't mul also be in xmm0 for WIN64? ie, I would have
> thought the prototype to be valid for WIN64 too.
> 
> Seeing this part below:
> 
>> +%if WIN64
>> +    SWAP 0, 2
>> +%endif
>> +%if ARCH_X86_32
>> +    VBROADCASTSS m0, mulm
>> +%else
> 
> It seems it really is ARCH_X86_32 vs _64. Also I don't understand the
> WIN64 block. But as I said, I rust quite fast.

In WIN64 there is a direct mapping between parameters and registers. So
because the float value here is the 3rd parameter, it will go in XMM2.
UNIX64, however, puts it in XMM0.

>> +    ALIGN 16
>> +.loop
> 
> I know surrounding code could have an impact on this, but does
> aligning improve anything here? Maybe the length of the loop allows
> it, but most often I don't see improvements with aligning nowadays.

I do see significant enough speed improvements in some cases. I'll
double check it here though.

-Justin


_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to