At least on SH there are several address mode selection issues which I'd like to group in this PR. PR 54065 [SH] Prefer @(R0,Rn) addressing for floating-point load/store PR 53911 [SH] Improve displacement addressing PR 50749 Auto-inc-dec does not find subsequent contiguous mem accesses PR 39423 [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn) PR 52049 SH Target: Inefficient constant address access Based on my observations so far, I think the right thing to do is to replace the current auto-inc-dec pass with a pass that optimizes address mode selection in a more generic way, instead of just trying to find auto inc/dec opportunities. The basic idea is to look at all memory accesses in a function (or basic block as a start) that share a base address and then try to select the cheapest addressing modes for each memory access. The current address cost target hook can be used to determine the costs of a memory access with a particular address. I have already started working on such a replacement pass a while ago and would like to first do a trial with the SH target. Other targets might then also pick it up if it seems beneficial to do so.
This surely sounds interesting. Like I suggested in PR62173, RTL optimizer might be able to do more in address expression re-association and addressing mode choosing. But it's difficult to change base/offset for addresses which are IVOPTed on GIMPLE.
(In reply to amker from comment #1) > This surely sounds interesting. Like I suggested in PR62173, RTL optimizer > might be able to do more in address expression re-association and addressing > mode choosing. > But it's difficult to change base/offset for addresses which are IVOPTed on > GIMPLE. (Proper) AMS is a difficult problem and depends a lot on the target address mode capabilities and the context of the memory accesses. I wouldn't try to do that on GIMPLE or in ivopt. There's simply not enough information on the instructions that will be used for actually carrying out the memory accesses. Whatever is done on GIMPLE without taking the target into account will result in missed optimization cases eventually. I would rather not distribute the AMS problem across sevaral compilation phases like doing a bit on GIMPLE and doing a bit on RTL later. Of course it'd be helpful if the tree optimizers can prepare some things that make AMS optimization more successful. But generally I think an AMS pass should be able to work on its own.
There is a GSoC 2015 project which will try to address the AMS problem. https://www.google-melange.com/gsoc/project/details/google/gsoc2015/erikvarga/5693417237512192 It will be initially for SH. If it works out, it can be generalized so that other targets can benefit from it, too.
The AMS branch is here: https://github.com/erikvarga/gcc