[llvm-dev] Reasoning about results of min and max with a constant

[Carlos Liam via llvm-dev]

I'm wondering if anyone would be willing to help me implement this.

 - CL

> On Aug 5, 2016, at 7:58 PM, Carlos Liam <carlos at aarzee.me> wrote:
> 
> I actually meant using the range analysis provided by LVI in computeKnownBits, instead of matching select patterns again in computeKnownBits. For example, consider this code:
> 
> // num is unsigned
> if (num < 4)
>   num = num & 4; // this can be proven to be 0
> 
> If we allowed computeKnownBits to work in conjunction with range analysis, we could optimize this case.
> 
>  - CL
> 
> On Aug 5, 2016, at 5:29 PM, David Majnemer <david.majnemer at gmail.com <mailto:david.majnemer at gmail.com>> wrote:
> 
>> Yes, I was proposing something like https://ghostbin.com/paste/r5uou <https://ghostbin.com/paste/r5uou>
>> 
>> On Fri, Aug 5, 2016 at 2:05 PM, Carlos Liam via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> Looks like LVI actually does have cases for max and min; would it be better to allow ValueTracking to use range analysis instead?
>> 
>>  - CL
>> 
>> > On Aug 1, 2016, at 8:44 PM, Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>> >
>> >> On 07/29/2016 07:08 PM, Carlos Liam via llvm-dev wrote:
>> >> Hi all,
>> >>
>> >> Say we have this IR:
>> >>
>> >> %1 = icmp slt i16 %x, 0
>> >> %.x = select i1 %1, i16 0, i16 %x
>> >>
>> >> This is the canonical form of what is effectively max(x, 0).
>> >>
>> >> From what I can tell LLVM has no facilities to determine from this code that %.x >= 0, so (for example) an SExt on %.x will not be converted to a ZExt.
>> >>
>> >> I'm interested in seeing what sorts of changes would be needed to recognize this pattern in existing facilities (computeKnownBits, etc.) in order to more broadly apply optimizations that use those facilities.
>> > LVI has a couple of special cases around select idioms.  This would be another reasonable one to add.  This would give range analysis (used in JumpThreading and CVP) for this idiom.  I thought we already had this one actually.
>> >>
>> >> Any insight would be appreciated. Thanks!
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> >
>> >
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160901/7931ed98/attachment.html>