[PATCH] Teach IndVarSimplify to add nuw and nsw to operations that provably don't overflow.

[Chandler Carruth]

On Mon, Dec 29, 2014 at 3:27 PM, Philip Reames <listmail at philipreames.com>
wrote:

> Well in essence that is what we are currently doing, usually by stripping
> the flags in the DAG.
>
> I think I wasn't quite clear enough.  We currently run InstCombine in
> multiple places in the pass ordering.  What if we had early runs of inst
> combine preserve flags as the first priority.  The runs closer to CGP would
> instead prioritize any legal optimization, regardless of whether it
> preserved flags or not.  Another way to state this would be that we simply
> pull the point we (potentially) drop flags a bit earlier in the pipeline -
> in particular, before the last point we run instcombine.
>

We have the DAG Combiner which is essentially the last combine run. It's
not InstCombine, but in theory this is where we would make such
transformations today.

What I'm trying to say is that we already have this in principle, we've
just pegged the "when" to be very late. We could move it forward if we had
some significant evidence doing so helped lots of things without making
anything worse, I just don't think anyone really has that kind of
information.

This of course doesn't help the fact that there are two competing canonical
forms. We end up picking one in the core of the pipeline and we will always
see tradeoffs from whichever form we pick (for example in knock-on
simplifications).

>
>  This doesn't really get us a butter practical result because the point
> of making the transform in instcombine is to allow the result to in turn
> re-combine with something else interestingly.
>
>  The "solution" I really know for this kind of thing is to explode the
> space by tracking both forms. We actually do some of this today. If you
> have an outer combine that needs an inner combine that strips flags, you
> just write the outer combine to handle the inner expression in its more
> complex flag-bearing form. The problem is that this grows the number of
> patterns necessary for the outer combine in a combinatorial way, so there
> are very severe limits on how much of this we can do.
>
> So essentially this comes down to a case by case profitability analysis
> and there's no good answer.  Understood.  :)
>
> One interesting observation is that, so far, the cases I've seen where
> missing flags inhibit optimization, those flags can be re-derived from the
> IR in it's current form (with sufficient effort).


I don't follow. The transforms which would require dropping flags would
fire in many more places than just the one that gave rise to this thread,
and would drop flags that we have no way of recomputing.

I don't think we're preserving flags in any cases where there is another
canonical form that is mathematically simpler and inherently preserves the
semantics. The problem is that the "simpler" form (thinking in terms of
arithmetically simpler) specifically makes the flags impossible to recover.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141229/d116ae36/attachment.html>