>> Are all your array indices uniformly sign-extended?<div>>> I don't know if this is a good idea, but why can't you consider the sext<br>>> operand the array index rather than the gep operand? If you prove that the<br>
>> narrow indices are disjoint, then the extended indices must be disjoint.<br>>> SCEV operations should work fine on the narrow indices which shouldn't have<br>>> any impure type casting operations.<br>
>><br>>> This can all be avoided by limiting your optimization to code that uses<br>>> pointer-size loop counters!<br>>><br>>> The array indices are out of my control; depends on the code people<br>
>> write. If they'd use long ints for everything, life would be good; but ints happen.<br>><br>> I thought array indices were promoted to a larger size when possible... This<br>> came up with Ada where loops with i8 counters are quite common. Dan added<br>
> logic to boost the size of the loop counters, but perhaps it doesn't promote<br>> them beyond i32, or doesn't apply here for some reason?<br><br>Here's an example I ran into today.<br><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<font face="courier new, monospace"><b>void miv7(int n, int A[][n], int *B) {<br> for (int i = 0; i < n; i++)<br> for (int j = 0; j < n; j++) {<br> A[2*i][4*j] = i;<br> *B++ = A[8*i][6*j + 1];<br> }<br>
}</b></font></blockquote><br><div>If I look at the store to A (src) and the load from A (dst), I see the following:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="courier new, monospace"><b>src = ((sext i32 {0,+,4}<%for.body3> to i64) +</b></font></div>
<div><font face="courier new, monospace"><b> ((zext i32 %n to i64) * (sext i32 {0,+,2}<%for.cond1.preheader> to i64)))</b></font></div><div><div><font face="courier new, monospace"><b>dst = ((sext i32 {1,+,6}<%for.body3> to i64) +</b></font></div>
<div><font face="courier new, monospace"><b> ((zext i32 %n to i64) * (sext i32 {0,+,8}<%for.cond1.preheader> to i64)))</b></font></div></div></blockquote><div><br></div><div>I speculate that some earlier analysis decided that since n is used as an array bound, it much be >= 0, and therefore unsigned.</div>
<div><br></div><div>If n, i, and j are all declared as long ints, I get the much cleaner</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="courier new, monospace"><b>src = {{0,+,(2 * %n)}<%for.cond1.preheader>,+,4}<%for.body3></b></font></div>
</div><div><div><font face="courier new, monospace"><b>dst = {{1,+,(8 * %n)}<%for.cond1.preheader>,+,6}<%for.body3></b></font></div></div></blockquote><div><br></div><div>which I can analyze accurately.</div><div>
<br></div><div>The manually linearized version</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="courier new, monospace"><b>void miv8(int n, int *A, int *B) {</b></font></div>
</div><div><div><font face="courier new, monospace"><b> for (int i = 0; i < n; i++)</b></font></div></div><div><div><font face="courier new, monospace"><b> for (int j = 0; j < n; j++) {</b></font></div></div><div>
<div><font face="courier new, monospace"><b> A[n*2*i + 4*j] = i;</b></font></div></div><div><div><font face="courier new, monospace"><b> *B++ = A[n*8*i + 6*j + 1];</b></font></div></div><div><div><font face="courier new, monospace"><b> }</b></font></div>
</div><div><div><font face="courier new, monospace"><b>}</b></font></div></div></blockquote><div><br></div><div>yields</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="courier new, monospace"><b>src = (sext i32 {{0,+,(2 * %n)}<%for.cond1.preheader>,+,4}<%for.body3> to i64)</b></font></div>
</div><div><div><font face="courier new, monospace"><b>dst = (sext i32 {{1,+,(8 * %n)}<%for.cond1.preheader>,+,6}<%for.body3> to i64)</b></font></div></div></blockquote><div><br></div><div>which is susceptible to Andy's idea of removing identical sign extensions before starting.</div>
<div><br></div><div>Preston</div><div><br></div></div>