This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH GCC]Fix PR57540, try to choose scaled_offset address mode when expanding array reference
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, Bin Cheng <bin dot cheng at arm dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 18 Jun 2013 16:02:10 +0200
- Subject: Re: [PATCH GCC]Fix PR57540, try to choose scaled_offset address mode when expanding array reference
- References: <1398126 dot DXY1Hx70QN at polaris> <1641021 dot yEjj6JVXb8 at polaris> <7796818 dot GJUC6Ilpof at polaris> <1371498747 dot 2356 dot 17 dot camel at yam-132-YW-E178-FTW> <CAHFci28gTwyxZ+KbZx==Ni68msjYSzwLnM=0SjV_9JJptx4C0Q at mail dot gmail dot com>
On Tue, 2013-06-18 at 18:09 +0800, Bin.Cheng wrote:
> On Tue, Jun 18, 2013 at 3:52 AM, Oleg Endo <oleg.endo@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