Thanks Eli.<div><br><div>Hal, yes, I agree. I imagine producing an listing with all sorts</div><div>of annotations concerning the success/failure of vectorization</div><div>and other loop xforms. Seems pretty essential as a tool to</div>
<div>help the performance-oriented programmer understand what's</div><div>happening in the compiler. Serves as a feedback mechanism,</div><div>teaching programmers what sorts of code can/can't be analyzed</div><div>
and transformed.</div><div><br></div><div>Preston</div><div><br></div><div><br><div class="gmail_quote">On Wed, Jun 20, 2012 at 5:50 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, 20 Jun 2012 02:18:49 -0700<br>
Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br>
<br>
> On Tue, Jun 19, 2012 at 10:21 PM, Preston Briggs<br>
> <<a href="mailto:preston.briggs@gmail.com">preston.briggs@gmail.com</a>> wrote:<br>
> > When compile the following case and look at the SCEV analysis, I<br>
> > notice that the first two loops don't have a<br>
> > LoopInvariantBackedgeTakenCount (surprising) and the last one does<br>
> > (not surprising, except in the context of the first two examples).<br>
> ><br>
> > void p4(int *A, int *B, long int n) {<br>
> >   for (char i = 0; i < n; i++) {<br>
> >     A[i + 2] = i;<br>
> >     *B++ = A[i];<br>
> >   }<br>
> > }<br>
> ><br>
> > void p5(int *A, int *B, long int n) {<br>
> >   for (short i = 0; i < n; i++) {<br>
> >     A[i + 2] = i;<br>
> >     *B++ = A[i];<br>
> >   }<br>
> > }<br>
> ><br>
> > void p6(int *A, int *B, long int n) {<br>
> >   for (int i = 0; i < n; i++) {<br>
> >     A[i + 2] = i;<br>
> >     *B++ = A[i];<br>
> >   }<br>
> > }<br>
> ><br>
> ><br>
> > Why the difference? Is there a reason we don't implement all the<br>
> > loops using 64-bit values?<br>
><br>
> The third loop is provably not an infinite loop, thanks to C's signed<br>
> overflow rules; we can't tell whether the first two loops might be<br>
> infinite.<br>
<br>
</div></div>This seems like a perfect example of where LLVM might want to emit a<br>
note to the user (especially when we have loop vectorization and other<br>
transformations).<br>
<br>
 -Hal<br>
<br>
><br>
> -Eli<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Hal Finkel<br>
Postdoctoral Appointee<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span></blockquote></div><br></div></div>