[PATCH GCC]Fix PR57540, try to choose scaled_offset address mode when expanding array reference

[Bin Cheng]

> -----Original Message-----
> From: Eric Botcazou [mailto:ebotcazou@adacore.com]
> Sent: Monday, June 17, 2013 3:32 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH GCC]Fix PR57540, try to choose scaled_offset address
mode
> when expanding array reference
> 
> > The problem occurs when accessing local array element. For example, #
> > VUSE <.MEM_27>
> > k_8 = parent[k_29];
> >
> > GCC calculates the address in three steps:
> > 1) addr is calculated as "r105 + (-2064)".
> > 2) offset is calculated as "r165*4".
> > 3) calls offset_address to combine the address into "r105+ r165*4 +
> > (-2064)".
> >
> > Since ADDR is valid and there is no call to memory_address_addr_space
> > in offset_address, the invalid address expression has no chance to go
> > through target dependent legitimization function.
> 
> But offset_address calls change_address_1 with validate set to 1 so during
RTL
> expansion memory_address_addr_space should be invoked on the invalid
address.
Yes, I missed that part.

> 
> > Even there is a chance, the
> > current implementation of memory_address_addr_space prevents the
> > scaled address expression from being generated because of below code:
> >       if (! cse_not_expected && !REG_P (x))
> > 	  x = break_out_memory_refs (x);
> 
> Where are the memory references in the above address?
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.

Thanks.
bin