On Mon, 2013-06-17 at 10:41 +0200, Eric Botcazou wrote: > > My mistake. It's because arm_legitimize_address cannot re-factor "[r105 + > > r165*4 + (-2064)]" into "rx = r105 + (-2064); [rx + r165*4]". Do you > > suggest that this kind of transformation should be done in backend? I can > > think of some disadvantages by doing it in backend: > > Different kinds of address expression might be wanted in different phase of > > compilation, for example, sometimes GCC wants to force computation of > > address expression out of memory access because it cannot CSE array > > indexing. It's difficult to differentiate in backend. > > It's equally difficult in memory_address_addr_space and it affects all the > architectures at once... You said in the original message that Thumb2 and > ARM > modes are already not equally sensitive to it, so it's not unthinkable that > some architectures might not want it at all. Therefore, yes, this should > preferably be handled in arm_legitimize_address.
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. Cheers, Oleg
