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

[Philip Reames]

On 12/29/2014 02:46 PM, Chandler Carruth wrote:
>
> On Mon, Dec 29, 2014 at 2:37 PM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>     On 12/23/2014 04:55 PM, Chandler Carruth wrote:
>>
>>     On Tue, Dec 23, 2014 at 4:51 PM, Sanjoy Das
>>     <sanjoy at playingwithpointers.com
>>     <mailto:sanjoy at playingwithpointers.com>> wrote:
>>
>>         > Perhaps it would help to explain it slightly differently:
>>         There are
>>         > optimizations which we can only perform by *removing* any
>>         no-wrap flags. But
>>         > we don't know whether that optimization or the no-wrap
>>         flags is more
>>         > important, and so we have to make a choice, and the choice
>>         is to preserve
>>         > the flags at the expense of the transformation. Thus,
>>         adding flags can
>>
>>         Is this choice always in favor of retaining the flags?  Or is
>>         it a
>>         per-transform decision?
>>
>>
>>     per-transform, but at least recently I've been seeing a trend
>>     towards preserving flags.
>>
>     Chandler, thanks for reframing this.   This suddenly makes a lot
>     more sense to me.  :)
>
>     This is starting to seem like an canonicalization issue. If we
>     canonicalized to the form with flags, and deferred flag stripping
>     until later in the optimization pipeline, would that get us a
>     better practical result? 
>
>
> 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.
>
> 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'm not sure we 
actually loose that much *in practice* by dropping flags and re-adding 
them later if safe to do.  Has anyone run any experiments on this?  I 
will freely admit I don't have a lot of experience here or a good grasp 
of the tradeoffs.

> Other approaches to this avoid "combining" and instead form axioms 
> about values so that they can represent multiple alternate axioms 
> throughout the optimization pipeline and select between them very late 
> rather than committing early. However, I'm not aware of any production 
> compilers that have managed to make this scale up. =/
>
> I think this is just a fundamental limitation of a combine-based (that 
> is, through mutations of the IR) scalar optimizer. The only way you 
> truly avoid it is to have a mutation-free scalar optimizer which would 
> just be a totally different design from LLVM's (IMO).
I think we're probably all in agreement that these are not practical 
answers.  :)

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141229/7c51a112/attachment.html>