From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1179 invoked by alias); 9 Apr 2007 19:13:42 -0000 Received: (qmail 1171 invoked by uid 22791); 9 Apr 2007 19:13:42 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Apr 2007 20:13:34 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l39JDVfp015280; Mon, 9 Apr 2007 15:13:31 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l39JDVmC027194; Mon, 9 Apr 2007 15:13:31 -0400 Received: from [10.13.248.120] (vpn-248-120.boston.redhat.com [10.13.248.120]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l39JDU33031702; Mon, 9 Apr 2007 15:13:30 -0400 Message-ID: <461A90E4.9070507@redhat.com> Date: Mon, 09 Apr 2007 19:13:00 -0000 From: "Vladimir N. Makarov" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 MIME-Version: 1.0 To: Zuxy Meng CC: gcc@gcc.gnu.org Subject: Re: x86 inc/dec on core2 References: <4617648A.2050808@gmail.com> <20070407141047.GA10237@lucon.org> <4618B7E7.2020005@gmail.com> <2FD44629-CBE1-42FA-88F6-799D9C09BD81@apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-04/txt/msg00268.txt.bz2 Zuxy Meng wrote: >"Mike Stump" >??????:2FD44629-CBE1-42FA-88F6-799D9C09BD81@apple.com... > > >>On Apr 8, 2007, at 2:37 AM, Uros Bizjak wrote: >> >> >>>My docs say that "INC/DEC does not change the carry flag". >>> >>> >>Personally, I'm having a hard time envisioning how the semantics of the >>instruction are relevant at all. This is all about instructing tuning, >>so, semantics cannot matter, otherwise, it would be wrong to make this a >>tune choice. >> >> > >Intel's optimization reference manual says that: > >3.5.1.1 Use of the INC and DEC Instructions >The INC and DEC instructions modify only a subset of the bits in the flag >register. This creates a dependence on all previous writes of the flag >register. This is especially problematic when these instructions are on the >critical path because they are used to change an address for a load on which >many other instructions depend. > >Assembly/Compiler Coding Rule 32. (M impact, H generality) >INC and DEC instructions should be replaced with ADD or SUB instructions, >because ADD and SUB overwrite all flags, whereas INC and DEC do not, >therefore creating false dependencies on earlier instructions that set the >flags. > > > That is probably one part of the true. Another part is that usage of inc/dec results in smaller code, better code locality and faster code. What is more important? This is hard to say. But I've checked SPEC2000 for gcc (revision 122995) again and see that usage of inc/dec gives not worse code (actually it is a bit better: 1939 without inc/dec vs 1944 with inc/dec for SPECInt2000 and 1724 vs 1727 for SPECFp2000) besides the code with usage of inc/dec is 0.39% for SPECInt and 0.11% for SPECFp smaller. Vlad