On Tue, 2013-06-18 at 18:09 +0800, Bin.Cheng wrote: > On Tue, Jun 18, 2013 at 3:52 AM, Oleg Endo <oleg.e...@t-online.de> wrote: > > > > My observation is, that legitimizing addressing modes in the backend by > > looking at one isolated address works, but doesn't give good results. > > In the SH backend there is this a particular case with displacement > > addressing (register + constant). On SH displacements for byte > > addressing are 0..15, 0..31 for 16 bit words and 0..63 for 32 bit words. > > sh_legitimize_address (or rather sh_find_mov_disp_adjust) uses a fixed > > heuristic to satisfy the displacement constraint and splits out a plus > > insn if needed to adjust the base address. Of course that fixed > > heuristic doesn't work for some cases and thus sometimes results in > > unnecessary base address adjustments. > > I had the idea of replacing the current (partially defunct) auto-inc-dec > > RTL pass with a more generic addressing mode selection pass: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56590 > > > > Any suggestions/comments/... are highly appreciated. > > > In PR56590, is PR50749 the only one that correlate with auto-inc-dec? > Others seem just problems of wrong addressing mode.
Yes, PR 50749 was the initial description of auto-inc-dec defects. PR 52049 is also related to it, as the code examples there are candidates for post-inc addressing mode. In that case, if 'int' is replaced with 'float' on SH post-inc is the optimal mode, because it doesn't have displacement addressing for FPU loads, except than SH2A. Even then, using post-inc is better as it has a more compact instruction encoding. The current auto-inc-dec is not able to discover such opportunities if, for example, mem accesses are reordered by preceding optimization passes. > And one point on PR50749, auto-inc-dec depends on ivopt to choose > auto-increment candidate. Since you disabled ivopt, I bet GCC will > miss lots of auto-increment opportunities. No, I haven't disabled ivopt. Cheers, Oleg
