From: "John S. Fine" <johnfine AT erols DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Optimizations
Date: Fri, 18 Sep 1998 11:44:18 -0400
Lines: 90
Message-ID: <36027FD2.329A@erols.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980918110932 DOT 17626E-100000 AT is>
Reply-To: johnfine AT erols DOT com
NNTP-Posting-Host: 207-172-241-24.s24.as5.bsd.erols.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Eli Zaretskii wrote:

> >   While debugging I noticed many place where gcc has
> > generated crude code that is both larger and slower
> > than I would have expected.
> 
> Maybe it's a good idea to post code fragments, the code emitted by GCC,
> and what you'd expect it to emit.

  I am trying to get GCC to emit the same excess instructions
in simple fragments that it does in my actual code.  In most
cases it doesn't.

  I noticed that many of the excess instructions are failures
of what I would call "scope reduction" (I don't know what
the coders of GCC call it).  Consider this snip of code which
is similar to things I do a lot:

  tmp = fun();
  if (tmp<0)
     return (tmp);

  The variable tmp is used several times in the routine.  Every
time it is used, it is first set and then referenced.  "Scope
reduction" is figuring out that each time tmp is set it is
a disconnected variable and does not need to be saved past the
immediate use.  In a simple routine the compiler must be doing
that scope reduction because the above code will use only eax
for tmp and not worry that the value is lost before the next
set of tmp:

	call _fun
	testl %eax,%eax
	jl L4

  In the live code the compiler emits:

	call _fun
	movl %eax,%ecx
	testl %ecx,%ecx
	jl L30

as if it hasn't recognised that this instance of tmp is
diconnected from all others.  I will try to find a simple
example of that.

  While looking for that I noticed another one that also
occurs in my live code:

void foo(void) {
   int index;
   for (index=5; index>0; index--)
      fun();
}

_foo:
	pushl %ebx
	movl $5,%ebx
	.align 2,0x90
L5:
	call _fun
	decl %ebx
	testl %ebx,%ebx
	jg L5
	popl %ebx
	ret

  Notice the testl %ebx,%ebx.  It isn't needed at all.

> Did you try the switches and the advice in section 14.2 of the DJGPP FAQ
> list (v2/faq211b.zip from the same place you get DJGPP).

  I looked there again and didn't see anything relevant to
these issues.

> >   GCC also adds NOPs to align many branch targets to
...
> > individually turn off optimizations like that while
...
> Yes, check out the "Optimization Options" section of the GCC on-line
> manual.

  I looked there again as well.  -fomit-frame-pointer will
probably help (I had forgotten it earlier).  But other than
that, I saw nothing relevant and nothing that addressed the
NOPs inserted for alignment.

-- 
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/