On Sat, Oct 24, 2015 at 7:03 PM, James Almer <jamr...@gmail.com> wrote:
> On 10/24/2015 7:48 PM, Ganesh Ajjanagadde wrote:
>> On Sat, Oct 24, 2015 at 6:08 PM, James Almer <jamr...@gmail.com> wrote:
>>> This gives the compiler some flexibility
>>>
>>> Signed-off-by: James Almer <jamr...@gmail.com>
>>> ---
>>> libavutil/x86/intmath.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
>>> index 7881e3c..10d3e7f 100644
>>> --- a/libavutil/x86/intmath.h
>>> +++ b/libavutil/x86/intmath.h
>>> @@ -36,7 +36,7 @@ static av_always_inline av_const int ff_ctzll_x86(long
>>> long v)
>>> {
>>> # if ARCH_X86_64
>>> uint64_t c;
>>> - __asm__("bsfq %1,%0" : "=r" (c) : "r" (v));
>>> + __asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));
>>> return c;
>>> # else
>>> return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v >> 32)) +
>>> 32 : _bit_scan_forward((uint32_t)v);
>>> --
>>> 2.6.2
>>
>> This question may be silly, but can you clarify when this asm code is
>> used instead of __builtin_ctzll? For instance, I think on GNU/Linux,
>> x86-64, sufficiently modern GCC (even with asm enabled), we should
>> always use the builtin: the compiler knows best what to do with its
>> builtin.
>
> This is ICC/ICL, not GCC.
Ah, now I recall that _bit_scan_forward64 was not always available on
ICC. Anyway, this is just a heads up to whoever uses ICC/ICL and the
like: you may want to find out to which versions this built in
applies.
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
