llvm dev - Jul 2016 - Reasoning about results of min and max with a constant

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.

Any insight would be appreciated. Thanks!

On Fri, Jul 29, 2016 at 10:08 PM, Carlos Liam via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
computeKnownBitsFromOperator is where the logic would go.  You'd
call matchSelectPattern with the select and if it gave back SPF_SMAX with
the RHS being zero, you'd know that it's a signed max with zero.

>
> Any insight would be appreciated. Thanks!
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> 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/20160730/fdd072db/attachment.html>

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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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> 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
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
>