[PATCH] Change APInt comparison with uint64_t.
Duncan P. N. Exon Smith
dexonsmith at apple.com
Wed Jun 24 15:40:26 PDT 2015
> On 2015 Jun 24, at 15:02, Paweł Bylica <chfast at gmail.com> wrote:
>
>> It's kind of gross to be calling into `ult()` and `==`, since those are
>> both non-trivial.
>>
>> IMO, you should implement these directly:
>> - sgt
>> - slt
>> - ugt
>> - ult
>>
>> And implement these trivially in terms of those:
>> - sge
>> - sle
>> - uge
>> - ule
>
> That might be a good idea. But because this patch can be controversial I would like not to include this optimization. The optimization should go with another patch even before this one. I would like also to measure the performance impact but I don't know how to do it. Is the test-suite the thing to use?
It's not really an optimization, it's just code reuse. But a separate
patch ahead of time makes sense. (1) change {g,l}e to use {g,l}t, and
then (2) change {g,l}e to do the right thing when BitWidth is small.
>
> Another case is `ult` and `==` asymmetry. There is a method called `eq` but without overloading for uint64_t. Should I add APInt::eq(uint64_t)?
If there's no potential minefield, you can just leave it I think. If
someone needs that function they can add it later.
More information about the llvm-commits
mailing list