On Wed, Jun 25, 2014 at 7:34 PM, Arthur O'Dwyer <[email protected]> wrote:
> On Wed, Jun 25, 2014 at 3:26 PM, Sanjin Sijaric <[email protected]> > wrote: > > > >> int *p; > >> typedef struct { > >> char a; > >> char b[100]; > >> char c; > >> } S; > >> > >> S x; > >> > >> void func1 (char d) { > >> for (int i = 0; i < 100; i++) { > >> x.b[i] += 1; > >> d = *p; > >> x.a += d; > >> } > >> } > >> > >> It seems like you want the compiler to hoist the read of `*p` above the > write to `x.b[i]`. > >> But that isn't generally possible, is it? because the caller might have > executed > >> > >> p = &x.b[3]; > >> > >> before the call to func1. > > > > Here, "p" is a pointer to int, whereas b is a char array. Wouldn't "p = > &x.b[3];" break ansi aliasing rules? > > I was under the impression that that was the entire point of "omnipotent > char"! > I think that's backwards from the intent: if you swap over 'int' and 'char' in the example, we cannot do the reordering, because p could point to (some byte of) one of the ints. With the test as-is, we *can* reorder the *p load (and even move it out of the loop): -- *p cannot alias x.b[i], because if 'x.b[i] += 1' has defined behavior, then x is an object of type S and x.b is an object of type char[100] and 0 <= i < 100, and therefore there is no int object aliased by that store -- *p cannot alias x.a, because if 'x.a += d' has defined behavior, then x is an object of type S, so a store to S::a cannot alias any int object. I think this kind of analysis should probably be covered by -fstruct-path-tbaa, not enabled by default, though. (I'm a little surprised that -fstruct-path-tbaa doesn't get this right today...) See lines 106-108 in the very file you're changing: > > 00106 // Character types are special and can alias anything. > 00107 // In C++, this technically only includes "char" and "unsigned > char", > 00108 // and not "signed char". In C, it includes all three. For now, > 00109 // the risk of exploiting this detail in C++ seems likely to > outweigh > 00110 // the benefit. > > Source: http://clang.llvm.org/doxygen/CodeGenTBAA_8cpp_source.html > > –Arthur > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
