On Sun, 2005-09-18 at 12:59 -0700, Richard Henderson wrote: > All this code in tree-data-ref.c is supposed to work on pointers, > isn't it?
Only in the absolute most basic of cases. Pointer data dependence is very non-trivial to do, which is why i wanted the MEM_REF stuff. > The comments seem to say so. No, it just doesn't completely *punt* on it, but they generally end up with access functions we can't work out, or aliasing we can't work out, etc. > > Except that it doesn't seem to work for even the simplest of test > cases. For instance, it reports dont_know for two uses of the > same SSA_NAME. > This doesn't fill me with confidence ... We have code on autovec to do more advanced data dependence testing. However, in general, data dependence testing on pointers is a losing proposition, because it involves a lot of aliasing work to determine whether you could have put one piece of memory in the way of the other, instead of just simple array dependence, where you know the aggregates are disjoint. > > Here's the test case I'm looking at with -O2 -ftree-vectorize. > We will lose the restrict info here, and think that image1 and image2 can point to the same thing, so we can't go further. > > r~ > > > typedef unsigned char auchar __attribute__ ((__aligned__(16))); > > #define MAX_LEN 1024 > #define WIDTH 8 > #define COLOR 128 > > void digital_chromakey(auchar * __restrict__ image1, > auchar * __restrict__ image2, unsigned long int len) > { > unsigned long int i; > unsigned char x, y; > > for (i = 0; i < WIDTH * len; i++) { > x = image1[i]; > y = image2[i]; > image1[i] = (x == COLOR ? y : x); > } > }