Matt Lee writes: > In any case, I am trying to optimize the case where there is clearly no > aliasing. Your suggestion regarding movmemsi is interesting. I have not used > this pattern before and assumed that it was required only when something > special must be done to do block moves. In my architecture, a block move is > not special and is equivalent a series of loads and stores. Why do I need > this pattern and why/how does the aliasing conflict become a non-issue when > defining this pattern?
When expanding this pattern you can take advantage of the fact that source and destination cannot overlap. Thus, you can expand the loads and stores more freely (see mips_block_move_straight). The type-based aliasing code does not retain this information so as soon as you are finished expanding RTL you have practically frozen the order of these instructions. I agree with you that you should not be required to provide this pattern but I don't think there is better way currently. We would need to subset the original alias set similarly to restrict but since memcpy switches the alias set of its operands to zero this approach would not work. Adam
