[llvm] r258184 - [SCEV] Fix PR26207
Andrew Trick via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 19 15:38:25 PST 2016
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 <mailto: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 <http://playingwithpointers.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160119/5c8058f5/attachment.html>
More information about the llvm-commits
mailing list