public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: bsamwel@xs4all.nl
To: gcc-gnats@gcc.gnu.org
Cc: bsamwel@xs4all.nl
Subject: optimization/10520: induction variable analysis not used to eliminate comparisons
Date: Mon, 28 Apr 2003 13:06:00 -0000	[thread overview]
Message-ID: <20030428125845.12859.qmail@sources.redhat.com> (raw)


>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:


                 reply	other threads:[~2003-04-28 13:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20030428125845.12859.qmail@sources.redhat.com \
    --to=bsamwel@xs4all.nl \
    --cc=gcc-gnats@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).