On Fri, Dec 06, 2013 at 12:30:54PM +0400, Konstantin Vladimirov wrote: > Consider code: > > int foo(char *t, char *v, int w) > { > int i; > > for (i = 1; i != w; ++i) > { > int x = i << 2; > v[x + 4] = t[x + 4]; > } > > return 0; > }
This is either job of ivopts pass, dunno why it doesn't consider turning those memory accesses to TARGET_MEM_REF with the *4 multiplication in there, or combiner (which is limited to single use though, so if you do say v[x + 4] = t[i]; int he loop instead, it will for -m32 put use the (...,4) addressing, but as you have two uses, it doesn't do it). As others said, the question is if using the more complex addressing more than once is actually beneficial or not. Anyway, while on this testcase, I wonder why VRP doesn't derive ranges here. <bb 3>: # RANGE [-2147483648, 2147483647] NONZERO 0x000000000fffffffc x_5 = i_1 << 2; # RANGE ~[2147483648, 18446744071562067967] NONZERO 0x0fffffffffffffffc _6 = (sizetype) x_5; # RANGE ~[2147483652, 18446744071562067971] NONZERO 0x0fffffffffffffffc _7 = _6 + 4; # PT = nonlocal _9 = v_8(D) + _7; # PT = nonlocal _11 = t_10(D) + _7; _12 = *_11; *_9 = _12; i_14 = i_1 + 1; <bb 4>: # i_1 = PHI <1(2), i_14(3)> if (i_1 != w_4(D)) goto <bb 3>; else goto <bb 5>; As i is signed integer with undefined overflow, and the loop starts with 1 and it is always only incremented, can't we derive # RANGE [1, 2147483647] # i_1 = PHI <1(2), i_14(3)> and similarly for i_14? We likely can't derive similar range for x_5 because at least in C++ it isn't undefined behavior if it shits into negative (or is it?), but at least with x = i * 4; instead we could. Jakub