From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-68557-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 31336 invoked by alias); 18 Feb 2003 17:55:27 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 31329 invoked from network); 18 Feb 2003 17:55:26 -0000
Received: from unknown (HELO mail.safelogic.se) (62.119.45.210)
  by 172.16.49.205 with SMTP; 18 Feb 2003 17:55:26 -0000
Received: from ivar.safelogic.se.safelogic (ivar.safelogic.se [192.168.100.12])
	by mail.safelogic.se (Postfix) with SMTP
	id D846FB69D; Tue, 18 Feb 2003 18:55:24 +0100 (CET)
Received: (nullmailer pid 8839 invoked by uid 3021);
	Tue, 18 Feb 2003 17:55:24 -0000
Date: Tue, 18 Feb 2003 18:13:00 -0000
From: =?iso-8859-1?Q?H=E5kan?= Hjort <hakan@safelogic.se>
To: Reza Roboubi <reza@linisoft.com>
Cc: gcc@gcc.gnu.org
Subject: Re: optimizations
Message-ID: <20030218175524.GA8638@safelogic.se>
References: <Pine.LNX.4.21.0301151338040.30377-100000@mail.kloo.net> <3E25F2BB.BA90B2C9@linisoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3E25F2BB.BA90B2C9@linisoft.com>
User-Agent: Mutt/1.4i
X-SW-Source: 2003-02/txt/msg01206.txt.bz2

Wed Jan 15 2003, Reza Roboubi wrote:
> tm_gccmail@mail.kloo.net wrote:
> [snap]
> > I mentioned this on the gcc-bugs mailing list, and Mark Mitchell
> > contributed a fairly simple load hoisting improvement to the loop
> > optmiizer which restored performance on Whetstone.
> > 
> > If you look at the gcc-bugs archives for 1998, you may be able to find
> > this message thread.
> [snap]
> 
> Thanks for this input. It would be interesting to see how the issue was fixed.
Sorry for getting into this so late.
Nobody actually posted the code generated by 3.3/3.4...

inline int mm(int *i) {
        if((*i)==0x10) return 0;
        (*i)++; return 1;
}

int main() {
        int k=0;
        while (mm(&k)) {}
        write(1,&k,1);
        return 0;
}

For Sun's Forte compiler one gets the following:

main:
         save    %sp,-104,%sp
         or      %g0,16,%g1
         st      %g1,[%fp-4]
         add     %fp,-4,%o1
         or      %g0,1,%o0
         call    write   ! params =  %o0 %o1 %o2 ! Result
         or      %g0,1,%o2
         ret     ! Result =  %i0
         restore %g0,0,%o0

I.e. it just stores '16' in k before the call to write, no trace left
of mm() or any loop, as should be.

Perhaps GCC now does the same after hoisting both the load and the store?

-- 
/Håkan