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

[Chandler Carruth]

On Mon, Dec 29, 2014 at 2:37 PM, Philip Reames <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> 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.

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. 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141229/9521a95a/attachment.html>