Hello, > >at the moment, any pass that needs to process memory references are > >complicated (or restricted to handling just a limited set of cases) by > >the need to interpret the quite complex representation of memory > >references that we have in gimple. For example, there are about 1000 of > >lines of quite convoluted code in tree-data-ref.c and about 500 lines in > >tree-ssa-loop-ivopts.c dealing with parsing and analysing memory > >references. > > I have my doubts changing this is the correct step forward. Having a > high level representation is a good thing and having it represented as > *(base+offset) (plus other info) might just make the other passes that > like the high level representation get worse. I also don't see why > tree-data-ref.c and tree-ssa-loop-ivopts.c could not use > get_inner_reference which parses the memory references for you.
for many reasons. Probably the most important is that you could not recover indices of multidimensional arrays this way, thus making dependency analysis impossible. Also, with pointer arithmetics, it is not sufficient just to call get_inner_reference, you also need to traverse SSA chains. Also, time and memory-wise, calling get_inner_reference is fairly expensive. Note that the representation I propose is not really low-level. It carefully preserves all the information you could get from the "high-level" representation (indices and their ranges, alias information). We already have low-level representation of memory references (TARGET_MEM_REFs), I do not feel any need to make an alternative proposal for that at the moment. > Maybe > I don't see the benifit in always changing our IR without really > thinking about the problem and seeing if there are already tools > (functions) which do the same thing in a common place. Sorry, but you are completely out here. I have spent a lot of time working with the code for dealing with memory references, trying many different approaches. Yes, I know about get_inner_reference, I use it where appropriate, and for many reasons (e.g., those mentioned above), it does not do the job in general. Also, I did not just pull the proposal out of thin air. I have read previous discussions regarding the topic, and I took the opportunity to ask how the memory references are represented in ICC (which turns out to be quite similar to my proposal). I assume that you are trying to help to get us towards some solution, however please note that some people could find remarks like this offensive. Zdenek
