[llvm] r258184 - [SCEV] Fix PR26207

[Hans Wennborg via llvm-commits]

This has been in a few days now. Sanjoy, do you want to merge this to
3.8 using the script in utils/release/merge.sh (or let me know if
you'd prefer me to do it).

Thanks,
Hans

On Tue, Jan 19, 2016 at 3:38 PM, Andrew Trick <atrick at apple.com> wrote:
> This fix looks safe to me too.
>
> Thanks Sanjoy!
>
> -Andy
>
> On Jan 19, 2016, at 3:26 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
> wrote:
>
> +CC Andy
>
> I'd wait for Andy to chime in, I think this is okay to merge into 3.8
> provided no problems are seen over the next 1-2 days.
>
>
>
> On Tue, Jan 19, 2016 at 2:34 PM, Hans Wennborg <hans at chromium.org> wrote:
>
> On Tue, Jan 19, 2016 at 12:53 PM, Sanjoy Das via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>
> Author: sanjoy
> Date: Tue Jan 19 14:53:51 2016
> New Revision: 258184
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258184&view=rev
> Log:
> [SCEV] Fix PR26207
>
> In some cases, the max backedge taken count can be more conservative
> than the exact backedge taken count (for instance, because
> ScalarEvolution::getRange is not control-flow sensitive whereas
> computeExitLimitFromICmp can be).  In these cases,
> computeExitLimitFromCond (specifically the bit that deals with `and` and
> `or` instructions) can create an ExitLimit instance with a
> `SCEVCouldNotCompute` max backedge count expression, but a computable
> exact backedge count expression.  This violates an implicit SCEV
> assumption: a computable exact BE count should imply a computable max BE
> count.
>
> This change
>
> - Makes the above implicit invariant explicit by adding an assert to
>   ExitLimit's constructor
>
> - Changes `computeExitLimitFromCond` to be more robust around
>   conservative max backedge counts
>
>
> Is this something that should be merged to 3.8?
>
>
>
>
> --
> Sanjoy Das
> http://playingwithpointers.com
>
>