From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16090 invoked by alias); 28 Apr 2003 13:06:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 16070 invoked by uid 71); 28 Apr 2003 13:06:01 -0000 Resent-Date: 28 Apr 2003 13:06:01 -0000 Resent-Message-ID: <20030428130601.16069.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, bsamwel@xs4all.nl Resent-Reply-To: gcc-gnats@gcc.gnu.org, bsamwel@xs4all.nl Received: (qmail 12860 invoked by uid 48); 28 Apr 2003 12:58:45 -0000 Message-Id: <20030428125845.12859.qmail@sources.redhat.com> Date: Mon, 28 Apr 2003 13:06:00 -0000 From: bsamwel@xs4all.nl Reply-To: bsamwel@xs4all.nl To: gcc-gnats@gcc.gnu.org Cc: bsamwel@xs4all.nl X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) X-GNATS-Notify: bsamwel@xs4all.nl Subject: optimization/10520: induction variable analysis not used to eliminate comparisons X-SW-Source: 2003-04/txt/msg01243.txt.bz2 List-Id: >Number: 10520 >Category: optimization >Synopsis: induction variable analysis not used to eliminate comparisons >Confidential: no >Severity: non-critical >Priority: medium >Responsible: unassigned >State: open >Class: pessimizes-code >Submitter-Id: net >Arrival-Date: Mon Apr 28 13:06:01 UTC 2003 >Closed-Date: >Last-Modified: >Originator: Bart Samwel >Release: gcc-3.2.3 >Organization: >Environment: Debian unstable as of 28/04/03 >Description: When I compile the following loop (please don't mind the excess of casts etcetera - this is generated code): unsigned int _tmp0= /* ... */; int* buf_fast= /* ... */; unsigned int n_in=0; unsigned int n_out=0; unsigned int n_in1=1; unsigned int n_out1=1; for(0;((n_in < _tmp0 && n_out < _tmp0) && n_in1 < _tmp0) && n_out1 < _tmp0;(((((n_in +=4,n_out +=2)),n_in1 +=4)),n_out1 +=2)){ buf_fast[(int)n_out]=buf_fast[(int)n_in]; buf_fast[(int)n_out1]=buf_fast[(int)n_in1]; } The assembler output for arch=pentium4 is: .L27: movl -72(%ebp), %eax movl (%edi,%eax,4), %eax movl %eax, (%edi,%ecx,4) movl (%edi,%esi,4), %eax addl $4, -72(%ebp) movl %eax, (%edi,%edx,4) addl $2, %ecx addl $4, %esi addl $2, %edx cmpl %ebx, -72(%ebp) jae .L23 cmpl %ebx, %ecx jae .L23 cmpl %ebx, %esi jae .L23 cmpl %ebx, %edx jb .L27 This loop contains a LOT of compares, which means that GCC doesn't induce that during the loop, the following things hold (with n = the iteration number): n_in = 0 + 4 * n n_in1 = 1 + 4 * n n_out = 0 + 2 * n n_out1 = 1 + 4 * n and therefore: n_in < n_in1 n_out <= n_in n_out1 <= n_in1 Because of these relations, it would be possible for GCC to induce that if n_in1 < _tmp0, then also n_in < _tmp0, n_out < _tmp0 and n_out1 < _tmp0. However, GCC doesn't seem to see the relationships between the variables. Oh, before you ask: no, I can't remove the unnecessary loop conditions. :( These are part of the compiled Cyclone code and are required by the Cyclone compiler so that it can optimize away the bounds checks on the array accesses. Optimizing away these inefficiencies is a back-end job, which is why I'm reporting this to GCC. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: