On 8/28/2017 12:08 PM, wm4 wrote:
> On Mon, 28 Aug 2017 11:52:52 -0300
> James Almer <[email protected]> wrote:
> 
>> AV_CPU_FLAG_MMX      == AV_CPU_FLAG_ARMV6 == AV_CPU_FLAG_ALTIVEC
>> AV_CPU_FLAG_3DNOWEXT == AV_CPU_FLAG_NEON
>> AV_CPU_FLAG_SSE      == AV_CPU_FLAG_VFP
>>
>> Signed-off-by: James Almer <[email protected]>
>> ---
>>  libavutil/cpu.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
>> index 5aef6af21..da857cd2c 100644
>> --- a/libavutil/cpu.c
>> +++ b/libavutil/cpu.c
>> @@ -20,6 +20,7 @@
>>  #include <stdint.h>
>>  #include <stdatomic.h>
>>  
>> +#include "attributes.h"
>>  #include "cpu.h"
>>  #include "cpu_internal.h"
>>  #include "config.h"
>> @@ -184,12 +185,20 @@ int av_cpu_count(void)
>>  
>>  size_t av_cpu_max_align(void)
>>  {
>> -    int flags = av_get_cpu_flags();
>> +    int av_unused flags = av_get_cpu_flags();
>>  
>> +#if ARCH_ARM || ARCH_AARCH64
>> +    if (flags & AV_CPU_FLAG_NEON)
>> +        return 16;
>> +#elif ARCH_PPC
>> +    if (flags & AV_CPU_FLAG_ALTIVEC)
>> +        return 16;
>> +#elif ARCH_X86
>>      if (flags & AV_CPU_FLAG_AVX)
>>          return 32;
>> -    if (flags & (AV_CPU_FLAG_ALTIVEC | AV_CPU_FLAG_SSE | AV_CPU_FLAG_NEON))
>> +    if (flags & AV_CPU_FLAG_SSE)
>>          return 16;
>> +#endif
>>  
>>      return 8;
>>  }
> 
> Wouldn't it be better to make the values disjoint?

That requires an ABI break and is not a good solution, especially when
it's only a "problem" in a function like this one outside of arch
specific folders.

Something like

size_t av_cpu_max_align(void)
{
    if (ARCH_AARCH64)
        return ff_get_cpu_max_align_aarch64();
    if (ARCH_ARM)
        return ff_get_cpu_max_align_arm();
    if (ARCH_PPC)
        return ff_get_cpu_max_align_ppc();
    if (ARCH_X86)
        return ff_get_cpu_max_align_x86();
    return 8;
}

Would be more in line with the rest of the codebase, but seems overkill
to me. I can send such an implementation anyway if that's preferred in
any case.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to