On Wed, 2013-06-19 at 22:42 +0800, Bin.Cheng wrote:
> On Tue, Jun 18, 2013 at 10:02 PM, Oleg Endo wrote:
> >
> > No, I haven't disabled ivopt.
> >
>
> But -fno-ivopts is specified in PR50749.
> With current implementation, auto-inc-dec iterates instructions
> backward, tries to find memory access
On Tue, Jun 18, 2013 at 10:02 PM, Oleg Endo wrote:
> On Tue, 2013-06-18 at 18:09 +0800, Bin.Cheng wrote:
>> On Tue, Jun 18, 2013 at 3:52 AM, Oleg Endo wrote:
>> >
>> > My observation is, that legitimizing addressing modes in the backend by
>> > looking at one isolated address works, but doesn't g
On Tue, 2013-06-18 at 18:09 +0800, Bin.Cheng wrote:
> On Tue, Jun 18, 2013 at 3:52 AM, Oleg Endo 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 pa
On Tue, Jun 18, 2013 at 3:52 AM, Oleg Endo wrote:
> 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 trans
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
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Monday, June 17, 2013 4:42 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 refere
> 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
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@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
> 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 "r
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Saturday, June 15, 2013 5:37 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 arra
> As reported in pr57540, gcc chooses bad address mode, resulting in A)
> invariant part of address expression is not kept or hoisted; b) additional
> computation which should be encoded in address expression. The reason is
> when gcc runs into "addr+offset" (which is invalid) during expanding, it
11 matches
Mail list logo
