public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "sje at cup dot hp dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/20643] New: Tree loop optimizer does worse job than RTL loop optimizer
Date: Fri, 25 Mar 2005 22:21:00 -0000	[thread overview]
Message-ID: <20050325222146.20643.sje@cup.hp.com> (raw)

In the attached test case, 3.4.* GCC generates better code than 4.0 (or 4.1)
because it moves more loop invariant code out of the inner loop of P7Viterbi. 
The problem seems to be in the alias analysis which determines what can be moved
out of that loop.  If you change the field M, which is unused, from int to float
then the 4.* GCC generates better code.  I tried the structure-alias branch to
see if that helped and it didn't.  See the email string starting at
http://gcc.gnu.org/ml/gcc/2005-03/msg00835.html for some more info.

Test case:

#define L_CONST 500

void *malloc(long size);

struct plan7_s {
  int M;
  int **tsc;                   /* transition scores     [0.6][1.M-1]        */
};

struct dpmatrix_s {
  int **mmx;
};
struct dpmatrix_s *mx;



void
AllocPlan7Body(struct plan7_s *hmm, int M) 
{
  int i;

  hmm->tsc    = malloc (7 * sizeof(int *));
  hmm->tsc[0] = malloc ((M+16) * sizeof(int));
  mx->mmx = (int **) malloc(sizeof(int *) * (L_CONST+1));
  for (i = 0; i <= L_CONST; i++) {
    mx->mmx[i] = malloc (M+2+16);
  }
  return;
}  

void
P7Viterbi(int L, int M, struct plan7_s *hmm, int **mmx)
{
  int   i,k;
  
  for (i = 1; i <= L; i++) {
    for (k = 1; k <= M; k++) {
      mmx[i][k] = mmx[i-1][k-1] + hmm->tsc[0][k-1];
    }
  }
}

main ()
{
	struct plan7_s *hmm;
	char dsq[L_CONST];
        int i;

	hmm = (struct plan7_s *) malloc (sizeof (struct plan7_s));
	mx = (struct dpmatrix_s *) malloc (sizeof (struct dpmatrix_s));
	AllocPlan7Body(hmm, 10);
        for (i = 0; i < 600000; i++) {
                P7Viterbi(500, 10, hmm, mx->mmx);
        }
}

-- 
           Summary: Tree loop optimizer does worse job than RTL loop
                    optimizer
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sje at cup dot hp dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-*-*
  GCC host triplet: ia64-*-*
GCC target triplet: ia64-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643


             reply	other threads:[~2005-03-25 22:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-25 22:21 sje at cup dot hp dot com [this message]
2005-03-25 22:58 ` [Bug tree-optimization/20643] " pinskia at gcc dot gnu dot org
2005-03-26  0:03 ` dberlin at dberlin dot org
2005-03-26  0:48 ` pinskia at gcc dot gnu dot org
2005-06-15  3:18 ` [Bug tree-optimization/20643] [4.0/4.1 Regression] " pinskia at gcc dot gnu dot org

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=20050325222146.20643.sje@cup.hp.com \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).