delorie.com/archives/browse.cgi   search  
Mail Archives: pgcc/2000/05/14/19:38:09

Date: Sun, 14 May 2000 22:23:40 +0200
From: Marc Lehmann <pcg AT goof DOT com>
To: Nick Kurshev <nickols_k AT mail DOT ru>
Cc: pgcc AT delorie DOT com
Subject: Re: pgcc-2.95.3
Message-ID: <20000514222340.E3351@cerebro.laendle>
Mail-Followup-To: Nick Kurshev <nickols_k AT mail DOT ru>, pgcc AT delorie DOT com
References: <E12r1JI-0001NV-00 AT base2 DOT mail DOT ru>
Mime-Version: 1.0
In-Reply-To: <E12r1JI-0001NV-00@base2.mail.ru>; from nickols_k@mail.ru on Sun, May 14, 2000 at 08:37:45PM +0000
X-Operating-System: Linux version 2.2.15 (root AT cerebro) (gcc version 2.95.1 19990816 (release))
Reply-To: pgcc AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: pgcc AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Sun, May 14, 2000 at 08:37:45PM +0000, Nick Kurshev <nickols_k AT mail DOT ru> wrote:
> I have some question. Could you please tell me:
> 
> 1. Would you like to add ENTER insn into PGCC when optimizing_size is true.

Hmm, that is an interesting idea. Difficult to make effective savings,
though. OTOH...

> 2. PGCC inlines many little functions like memcpy, strlen e t.c.

You can use -fno-builtin to disable use of built-ins. Your libc, however,
might still want to create inline code, though.

> Why I have such different assembler output?

Because you requested optimization for different cpu's. i386 are faster
with the latter loop, i486 (or pentii?) and above are faster with the
former loop.

> Btw -O2 and -Os in this case do not differ.  IMHO, second output much
> better in all case that first (and small and fast).

Benchmark first, think second!

> For which CPU first output is optimized?

The cpu you configured your compiler for.

> After analyze of second output I see, that insn MOV $-1, %ecx can be
> safety replaced with OR $-1, %ecx where length of $-1 = 1 byte, that
> can reduce size of code. Also in many other cases (not only inline
> functions) such optimization can be applied.

This is true ;) There are many cases like this that are useful when
optimizing for size. I'll look into this (someday!).

> 3. I wrote some abstract function:
> 
> #include <string.h>
> #include <stdio.h>
> 
> int my_func(char *str,const char *str2,unsigned i)
> {
>   memmove(str,str2,i);
>   return isatty(stdin);
> }
> 
> Beginning of function %esp is assigned value twice and at end of function %esp is incremented twice. This is 
> the most frequently case for many functions. Even key -O6 does not change anything.

This is true. It is also very difficult to optimize. The next version of
gcc (and pgcc) will have this optimized.

Thanks a lot for your comments!!

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg AT opengroup DOT org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019