<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Nov 25, 2013, at 4:39 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">----- Original Message -----<br><blockquote type="cite">From: "Andrew Trick" <<a href="mailto:atrick@apple.com">atrick@apple.com</a>><br>To: "Sebastian Pop" <<a href="mailto:spop@codeaurora.org">spop@codeaurora.org</a>><br>Cc: "llvm commits" <<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>><br>Sent: Monday, November 25, 2013 6:07:39 PM<br>Subject: Re: Bug 16358: simplify SCEVs with assumptions<br><br><br>On Nov 25, 2013, at 10:56 AM, Sebastian Pop <<a href="mailto:spop@codeaurora.org">spop@codeaurora.org</a>><br>wrote:<br><br><blockquote type="cite">Hi,<br><br>I have started looking at SCEV simplify in the context of<br>determining the number<br>of iterations for this loop:<br><br>void foo(int n, int *A) {<br>for (short i = 0; i < n; i++)<br> A[i] = 0;<br>}<br><br>where the niter computation is confused and answers "could not<br>compute" because<br>the SCEV representation of %i contains a zext expression.<br><br>Now supposing that we remove the zext in "Expr = zext(Op i16 to<br>i32)" by<br>replacing the zext with a cast(Op, i32) and this under the<br>assumption that Expr<br>has values in range:<br>ConstantRange Range = SE.getUnsignedRange(Expr);<br><br>With this simplified representation of %i, niter ends up with a<br>number of<br>iterations of the form "%n". This assumption will then impact the<br>computation of<br>other SCEVs, like the value of %i at the end of the loop, etc., and<br>with<br>ScalarEvolution's caching, the same assumptions will be used in<br>other niter or<br>scev analysis queries, making it almost impossible to say which SE<br>results have<br>used the assumptions and which are independent.<br><br>For this reason I was thinking that the set of assumptions should<br>be part of the<br>state of the ScalarEvolution, and thus users of the SCEV should<br>either version<br>the transformed code with the assumptions, or otherwise if<br>versioning is not<br>possible, clear out the caches of ScalarEvolution and restart the<br>analysis under<br>no assumptions.<br></blockquote><br>I'm nervous about managing SCEV caches that depend on query context<br>because it is so hard to test and reason about the correctness, and<br>it’s hard to know if compile time will become unbounded. Do we<br>really need to solve this problem?<br><br>If the trip count computation could directly analyze expressions of<br>this form:<br><br> %conv = sext i16 %inc to i32<br> --> (sext i16 {1,+,1}<%for.body> to i32)<br><br>And gather assumptions during the analysis, then SCEV simplification<br>doesn't need to do the work. (In fact I think we should do less work<br>in SCEV simplification).<br><br>Say we had a utility, e.g. ScalarEvolution::promoteIV, that would<br>take a SCEV of the form:<br>(sext i16 {1,+,1}<%for.body> to i32)<br><br>And return a new SCEV:<br>{1,+,1}<%for.body><br></blockquote><br>I think that the underlying issue is: do you put nsw on this expression?<br></div></blockquote><div><br></div>No. Anyone using this result needs to prove the “i < 2**16" assumption or add a constraint to the loop.</div><div><br></div><div>I think we can do more with trip count and dependence analysis queries without SCEV NSW flags... They were just convenient initially.</div><div>-Andy</div><div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">-Hal<br><br><blockquote type="cite"><br>Along with it's set of assumptions:<br>"{1,+,1}<%for.body>" < 2**16<br><br>We can always factor code between getSignExtendExpr and promoteIV,<br>but I'm only looking at a few lines of code to do this.<br><br>It up to the caller to prove the assumption as a loop precondition,<br>undefined behavior inference, or whatever. In the case of trip count<br>computation, HowManyLessThans would prove the assumptions that it<br>can and report the rest to the client of the trip count query.<br>Aggressive loop opts, like LoopVectorizer, can gather the<br>assumptions from various queries and materialize the minimum number<br>of constraints such that they all hold. SCEV could provide a utility<br>to optimize the constraints.<br><br>-Andy<br><br><blockquote type="cite"><br>Sebastian<br><br>Arnold Schwaighofer wrote:<br><blockquote type="cite"><br>On Oct 11, 2013, at 4:17 PM, Sebastian Pop <<a href="mailto:spop@codeaurora.org">spop@codeaurora.org</a>><br>wrote:<br><br><blockquote type="cite">Arnold Schwaighofer wrote:<br><br><blockquote type="cite">Interesting, in such a framework - if I understand you correctly<br>- whenever we<br>simplify an expression we would have to try several assumptions:<br>a harder<br></blockquote><br>I think SCEV folding could compute the assumptions needed to<br>simplify the<br>expression. Let's take the example from the bug report:<br><a href="http://llvm.org/bugs/show_bug.cgi?id=16358">http://llvm.org/bugs/show_bug.cgi?id=16358</a><br><br><blockquote type="cite">8 * (zext i32 ({0,+,2}%<for_body>) to i64)+ %C_aligned<br>8 * (zext i32 ({1,+,2}%<for_body>) to i64)+ %C_aligned<br>Without knowing that for the loop <for_body> the functions<br>"{0,+,2}%<for_body>"<br>and "{1,+2}%<for_body>" don?t wrap, SCEV cannot remove the zext.<br></blockquote><br>simplify would recursively reconstruct the SCEV, so it would<br>first dive in the<br>innermost expression, and the first assumption it would extract<br>is from<br>simplifying (zext i32 ({0,+,2}%<for_body>) to i64)<br><br>simplify(zext i32 ({0,+,2}%<for_body>) to i64) =<br>{0,+,2}%<for_body> assuming<br>{0,+,2}%<for_body> does not wrap, i.e., 2*N < 2**32<br><br>simplify would produce two constraints:<br><br>2*N < 2**32<br>2*N+1 < 2**32<br><br>we should keep the one satisfying both simplified expressions:<br>2*N+1 < 2**32<br></blockquote><br><br>Okay, I see now. I was looking at the problem top down - hence a<br>tree of<br>decisions :) - and was worried that for some examples we would<br>have to guess a<br>value. But bottom up we should have already seen such values.<br>Right.<br></blockquote><br><br>--<br>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,<br>hosted by The Linux Foundation<br></blockquote><br><br>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br><br></blockquote><br>--<span class="Apple-converted-space"> </span><br>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory</div></blockquote></div><br></body></html>