[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