[PATCH] D15232: [InstCombine] Aggressively fold compares that can be discovered to be constant

James Molloy via llvm-commits llvm-commits at lists.llvm.org
Sat Dec 5 11:34:54 PST 2015


Hi Philip,

Thanks for taking a look!

I agree that searching an arbitrary size value graph would be horrendously
expensive. What I have implemented is to search through unlimited selects
and phis (should be cheap, these aren't commonly chained deeply, see
GetUnderlyingObjects), and will look through only a certain number of
binary operators. The default depth is 1, which will go through one add but
no more (configurable by the user). I think overall this should restrict
the potential for bloat.

I have a motivating example which is a chain of selects and phis in a loop.
The loop part is important - it's what seems to confuse instcombine
currently. What I can do is take a look to see what's causing CVP / LVI to
not support this case and report back. Thanks for the hint!

I'm not sure the last approach you suggested would work for the loop use
case, although I haven't thought majorly hard about it just yet.

Thanks again,

James
On Fri, 4 Dec 2015 at 20:36, Philip Reames via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> reames added a subscriber: reames.
> reames added a comment.
>
> At a high level, I'm a bit unsure about the formulation chosen here.  I'm
> worried that seeking to find a set of constant values through a potentially
> large value graph might be expensive.
>
> A couple of specific questions:
>
> - The examples you've listed should be entirely handled by LazyValueInfo
> and either JumpThreading or CVP.  Do you have a strong reason InstCombine
> needs to perform the same optimization?
> - Have you considered phrasing this as pushing the query (i.e. icmp) back
> along the inputs?  Doing this might a) let you terminate earlier or b)
> unswitch the comparison if the select is only used by the compare.
>
>
> http://reviews.llvm.org/D15232
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151205/ff6e9ac9/attachment.html>


More information about the llvm-commits mailing list