public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: Oskar Enoksson <osken393@student.liu.se>
Cc: egcs@egcs.cygnus.com
Subject: Re: Optimization
Date: Mon, 29 Mar 1999 08:18:00 -0000	[thread overview]
Message-ID: <876.922704204@upchuck> (raw)
In-Reply-To: <Pine.SGI.3.96.980326123604.8153E-100000@purcell>

  In message <Pine.SGI.3.96.980326123604.8153E-100000@purcell>you write:
  > 
  > Hi! I'm working with computational mathematics using c and c++.
  > 
  > Does g++/gcc have any optimization that brings out constant subexpressions
  > outside loops? Consider the following:
  > 
  > void sqr(float *x, int *step) {
  >   int i,j,k;
  > 
  >   for (i=0; i<100; i++)
  >     for (j=0; j<100; j++)
  >       for (k=0; k<100; k++)
  >         *(x+i*step[2]+j*step[1]+k*step[0]) *= 
  >           *(x+i*step[2]+j*step[1]+k*step[0]);
  > }
  > 
  > The resulting assembler with egcs 1.0.2 (i686-pc-linux-gnulibc1) is not
  > very efficient, because the integer expressions are calculated again
  > and again inside the innermost loop. Can I make the compiler translate the
  > above code into something like the following:
  > 
  > void sqr(float *x, int *step) {
  >   int i,j,k; 
  >   float *xi,*xj;
  > 
  >   for (i=0; i<100; i++) {
  >     xi=x+i*step[2];
  >     for (j=0; j<100; j++)  {
  >       xj=xi+j*step[1];
  >       for (k=0; k<100; k++)  {
  >         *(xj+k*step[0]) *=
  >           *(xj+k*step[0]);
  >       }
  >     }
  >   }
  > }
  > 
  > If this is impossible with the current version, would it be hard to
  > add this optimization to the compiler? The resulting assembler is much
  > more efficient.
An FYI -- current development snapshots perform this optimization and thus
egcs-1.2 will perform this optimization when released.

This optimization was made possible by Mark Mitchell's type based alias
analysis will allows the compiler to realize that the floating point stores
in the loop can not access the same memory as the integer loads that were
initially in the loop.  This exposes the integer loads to loop invariant
code motion optimizations.


jeff

WARNING: multiple messages have this Message-ID
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: Oskar Enoksson <osken393@student.liu.se>
Cc: egcs@egcs.cygnus.com
Subject: Re: Optimization
Date: Wed, 31 Mar 1999 23:46:00 -0000	[thread overview]
Message-ID: <876.922704204@upchuck> (raw)
Message-ID: <19990331234600.YOCAfqWq7leQrgitH8DGdZbGhT3fZmCc46egmN6BRcs@z> (raw)
In-Reply-To: <Pine.SGI.3.96.980326123604.8153E-100000@purcell>

  In message <Pine.SGI.3.96.980326123604.8153E-100000@purcell>you write:
  > 
  > Hi! I'm working with computational mathematics using c and c++.
  > 
  > Does g++/gcc have any optimization that brings out constant subexpressions
  > outside loops? Consider the following:
  > 
  > void sqr(float *x, int *step) {
  >   int i,j,k;
  > 
  >   for (i=0; i<100; i++)
  >     for (j=0; j<100; j++)
  >       for (k=0; k<100; k++)
  >         *(x+i*step[2]+j*step[1]+k*step[0]) *= 
  >           *(x+i*step[2]+j*step[1]+k*step[0]);
  > }
  > 
  > The resulting assembler with egcs 1.0.2 (i686-pc-linux-gnulibc1) is not
  > very efficient, because the integer expressions are calculated again
  > and again inside the innermost loop. Can I make the compiler translate the
  > above code into something like the following:
  > 
  > void sqr(float *x, int *step) {
  >   int i,j,k; 
  >   float *xi,*xj;
  > 
  >   for (i=0; i<100; i++) {
  >     xi=x+i*step[2];
  >     for (j=0; j<100; j++)  {
  >       xj=xi+j*step[1];
  >       for (k=0; k<100; k++)  {
  >         *(xj+k*step[0]) *=
  >           *(xj+k*step[0]);
  >       }
  >     }
  >   }
  > }
  > 
  > If this is impossible with the current version, would it be hard to
  > add this optimization to the compiler? The resulting assembler is much
  > more efficient.
An FYI -- current development snapshots perform this optimization and thus
egcs-1.2 will perform this optimization when released.

This optimization was made possible by Mark Mitchell's type based alias
analysis will allows the compiler to realize that the floating point stores
in the loop can not access the same memory as the integer loads that were
initially in the loop.  This exposes the integer loads to loop invariant
code motion optimizations.


jeff

  parent reply	other threads:[~1999-03-29  8:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-03-29  5:14 Optimization Oskar Enoksson
1998-04-02  3:41 ` Optimization John Carr
1998-04-02  8:21 ` Optimization Jeffrey A Law
1998-04-02 11:32 ` Optimization Joern Rennecke
1998-04-02 11:32 ` Optimization Jim Wilson
1998-04-02  3:41   ` Optimization Oskar Enoksson
1998-04-03 21:52     ` Optimization John Carr
1999-03-29  8:18 ` Jeffrey A Law [this message]
1999-03-31 23:46   ` Optimization Jeffrey A Law
1999-03-30  5:07 Optimization Oskar Enoksson
1999-03-31 23:46 ` Optimization Oskar Enoksson
2000-05-11 11:21 Optimization Thomas, Robert S
2000-05-11 11:31 ` Optimization Jeffrey A Law
2003-05-02 12:05 Optimization Piotr Wyderski
2003-05-02 23:08 ` Optimization Richard Henderson
2003-05-03  0:12   ` Optimization Andrew Pinski
2003-05-03  1:14     ` Optimization Richard Henderson
2003-12-09 16:42 optimization Viktor Przebinda
2003-12-09 17:29 ` optimization Diego Novillo
2003-12-09 18:53 ` optimization Scott Robert Ladd
2003-12-09 18:18 optimization Benjamin Kosnik

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=876.922704204@upchuck \
    --to=law@upchuck.cygnus.com \
    --cc=egcs@egcs.cygnus.com \
    --cc=osken393@student.liu.se \
    /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).