public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Rahul Kharche" <rahul@IceraSemi.com>
To: "Bernd Schmidt" <bernds_cb1@t-online.de>
Cc: <gcc@gcc.gnu.org>, 	"sdkteam-all" <sdkteam-all@IceraSemi.com>
Subject: RE: [4.5] Find more autoinc addressing for induction variables
Date: Fri, 22 May 2009 15:47:00 -0000	[thread overview]
Message-ID: <4D60B0700D1DB54A8C0C6E9BE69163700A186C3E@EXCHANGEVS.IceraSemi.local> (raw)
In-Reply-To: <4A0E031F.7030007@t-online.de>

Hi,

I am trialing this patch on a private GCC port that I'm working on.
The patch works well with several test cases we have. However, fails
on the following

int
main ()
{
  const int arr[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
  int i;

  for (i = 0; i < 10; i++)
    {
      printf("arr[%d] : %d\n", i, arr[i]);
    }
}

Looking at the pass dump it seems the SSA re-scan of the symbol 'arr'
marks its use inside the loop as volatile

<bb 2>:
  arr[0] = 1;
  arr[1] = 2;
  arr[2] = 3;
  arr[3] = 4;
  arr[4] = 5;
  arr[5] = 6;
  arr[6] = 7;
  arr[7] = 8;
  arr[8] = 9;
  arr[9] = 10;
  __builtin_loop_start (1, 9);
  ivtmp.42_23 = (long unsigned int) &arr[1];

<bb 3>:
  # i_19 = PHI <i_6(4), 0(2)>
  # prephitmp.14_18 = PHI <pretmp.13_1(4), 1(2)>
  # ivtmp.42_21 = PHI <ivtmp.42_22(4), ivtmp.42_23(2)>
  __builtin_loop_iteration (1);
  printf (&"arr[%d] == var : %d\n"[0], i_19, prephitmp.14_18);
  i_6 = i_19 + 1;
  if (i_6 != 10)
    goto <bb 4>;
  else
    goto <bb 5>;

<bb 4>:
  pretmp.13_1 ={v} MEM[index: ivtmp.42_21];
  ivtmp.42_22 = ivtmp.42_21 + 4;
  goto <bb 3>;

<bb 5>:
  return;


And subsequently dead code elimination removes the array initialization
completely.

<bb 2>:
  __builtin_loop_start (1, 9);
  ivtmp.42_23 = (long unsigned int) &arr[1];

<bb 3>:
  # i_19 = PHI <i_6(4), 0(2)>
  # prephitmp.14_18 = PHI <pretmp.13_1(4), 1(2)>
  # ivtmp.42_21 = PHI <ivtmp.42_22(4), ivtmp.42_23(2)>
  __builtin_loop_iteration (1);
  printf (&"arr[%d] == var : %d\n"[0], i_19, prephitmp.14_18);
  i_6 = i_19 + 1;
  if (i_6 != 10)
    goto <bb 4>;
  else
    goto <bb 5>;

<bb 4>:
  pretmp.13_1 ={v} MEM[index: ivtmp.42_21];
  ivtmp.42_22 = ivtmp.42_21 + 4;
  goto <bb 3>;

<bb 5>:
  return;

}

Rahul


-----Original Message-----
From: gcc-patches-owner@gcc.gnu.org
[mailto:gcc-patches-owner@gcc.gnu.org] On Behalf Of Bernd Schmidt
Sent: 16 May 2009 01:05
To: Steven Bosscher
Cc: GCC Patches; F. Kenneth Zadeck; Zdenek Dvorak
Subject: Re: [4.5] Find more autoinc addressing for induction variables

I wrote:

> I'll see whether I can achieve a similar effect by modifying 
> tree-ssa-loop-ivopts instead.  Maybe I can add new candidates that get

> incremented in suitable basic blocks other than just the last one.

So here's a draft of what that would look like.  For every use/cand pair
for which autoinc is possible (which now requires that the use's block
is not in a nested loop, and dominates the latch), we create a new
candidate which is incremented at the point of the use, and compute its
cost without including the cost of the step.  This also gets rid of the
special handling in iv_ca_recount_cost.

That could be extended later to have candidates that are incremented
several times, e.g. to create two 16-bit postinc addressing modes for a
candidate that's incremented by 4.

Does this look like an approach that everyone can live with?


Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

       reply	other threads:[~2009-05-22 13:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <49998A2D.5000401@t-online.de>
     [not found] ` <4A0AED10.7070109@t-online.de>
     [not found]   ` <571f6b510905131427p30afe791h65118fca411f2ed@mail.gmail.com>
     [not found]     ` <4A0B54D2.4030208@t-online.de>
     [not found]       ` <571f6b510905131558g272ad0f2u2bb4fe5d613f2c3b@mail.gmail.com>
     [not found]         ` <4A0C4F06.3080707@t-online.de>
     [not found]           ` <571f6b510905141426t1ec4a7e6i2bd69d90362f394@mail.gmail.com>
     [not found]             ` <4A0D4D12.1050607@t-online.de>
     [not found]               ` <571f6b510905150525g22898204p340aa5540644f5bd@mail.gmail.com>
     [not found]                 ` <4A0D8599.7080305@t-online.de>
     [not found]                   ` <4A0E031F.7030007@t-online.de>
2009-05-22 15:47                     ` Rahul Kharche [this message]
2009-05-22 16:59                       ` Bernd Schmidt
2009-05-22 18:04                         ` Rahul Kharche
2009-05-22 19:05                         ` Rahul Kharche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D60B0700D1DB54A8C0C6E9BE69163700A186C3E@EXCHANGEVS.IceraSemi.local \
    --to=rahul@icerasemi.com \
    --cc=bernds_cb1@t-online.de \
    --cc=gcc@gcc.gnu.org \
    --cc=sdkteam-all@IceraSemi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).