On Sun, Oct 25, 2015 at 9:46 AM, Ganesh Ajjanagadde
<gajjanaga...@gmail.com> wrote:
> On Sat, Oct 24, 2015 at 9:38 PM, Mark Harris <mark....@gmail.com> wrote:
>>>>
>>>> static int compare_int64(const void *a, const void *b)
>>>> {
>>>> - int64_t va = *(int64_t *)a, vb = *(int64_t *)b;
>>>> - return va < vb ? -1 : va > vb ? +1 : 0;
>>>> + return *(const int64_t *)a - *(const int64_t *)b;
>>>> }
>>>>
>>>
>>> What if the result doesn't fit in int? The input is not int.
>>
>> Even for int this transformation is not valid assuming that the full
>> range of int is possible. For example if *a = INT_MAX and *b = -1
>> then *a - *b = INT_MAX+1 which is negative when cast to an int.
>
> point taken, but this will need to be checked more carefully: for
> instance, sometimes the integers fit in only the lower 24/16 bits,
> etc. I have decided the following: this patch will only address the
> const-ness. The next patch will be a scan through the qsort
> comparators, and appropriately modifying the comparator by fixing
> existing issues (if any) related to your point, and avoiding branches
> when possibles.
Seems like the (x > y) - (x < y) trick works very well: GCC optimizes
it to branch-less code, and it is overflow safe:
https://stackoverflow.com/questions/10996418/efficient-integer-compare-function/10997428#10997428
Will submit patch to convert all qsort comparators (the ones for
integers) to this form, yielding two benefits:
1. Branchless code.
2. Consistency across the codebase.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
