Hello, > >> This looks like a very complicated (though very generic) way of > >> specifying a memory > >> reference. Last time we discussed this I proposed to just have BASE, > >OFFSET > >> and accessed TYPE (and an alias tag of the memory reference). I realize > >> this > >> doesn't cover accesses to multi-dimensional arrays, but using the > >> full-blown scheme > >> in place of a simple INDIRECT_REF makes memory usage for the trees go up > >> noticable. > > > >by the way, does your claim "using the full-blown scheme... makes memory > >usage go up noticeable" mean that you have experimented with some > >similar representation? If so, could you please post your > >patches/results? Or do you have at least some data regarding how great > >part of the tree memory consumption comes from memory references? > > No, I didn't do patches or measurements. I just extrapolated that if you > want > to handle things like a.x[i].y.z[j] you need to store not only two indices > but > either two strides or two types (to extract the stride). So you'd > have (assuming > a flat tree) for example two VECs in the memory reference tree. Together > with the (possibly non-constant) offset and the base these are four pointers > compared to one in a simple INDIRECT_REF.
to make this comparison fair, you also need to take into account that the computations need to be done somewhere. So for the "simple INDIRECT_REF", you in fact have the following statements in the program (assuming that lower bound of each array is 0, otherwise you would also have the subtractions): off1 = step1 * i; off2 = step2 * i; off = off1 + off2; addr = base + off; *addr Given all the temporary variables, expression and assignment nodes needed for this, this more than makes up for any extra space that is used in the proposed representation. Of course, in some situations some of these computations may be shared. For simple INDIRECT_REF (without any structure), we store base, plus we have fields for offset (constant 0) and the vector of indices (NULL). So there are two extra pointers over the current state. Without experimentation, I cannot tell whether overall, my proposal would require more or less memory than we use now. In fact, if this turned out to be a problem, I can live with allowing also INDIRECT_REF in its current form, to represent references that do not have any structure. > Maybe we can incrementally create out of all the existing memory reference > two reference trees, one simple that does not handle multi-dimensional array > accesses well and one full-blown one? Would not that just mean that you would consume even more memory? If you mean incremental lowering, yes, I can imagine we might want to do that (possibly lowering the references later to the existing TARGET_MEM_REFs), but it does not really help with the memory consumption. Zdenek
