You Win :)
On 28-okt-03, at 17:27, Shih Ming-Wei wrote:
This is not true (or outdated) see below.
-O also turns on -fomit-frame-pointer on machines
where doing so does not interfere with debugging.
I thinks only on VAX -fomit-frame-pointer does not affect debugging
(I know nothing about VAX, just follow the gcc docs), so basically
on all other ARCH -O, -O1 and -O2 (and -O3 ans -Os) do not imply
-fomit-frame-pointer
Taken
from:http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Optimize-
Options.html#Optimize%20Options
-O1
Optimize. Optimizing compilation takes somewhat more time, and a
lot more memory for a large function.
With -O, the compiler tries to reduce code size and execution
time, without performing any optimizations that take a great deal of
compilation time.
-O turns on the following optimization flags:
-fdefer-pop
-fmerge-constants
-fthread-jumps
-floop-optimize
-fcrossjumping
-fif-conversion
-fif-conversion2
-fdelayed-branch
-fguess-branch-probability
-fcprop-registers
-O also turns on -fomit-frame-pointer on machines where doing so
does not interfere with debugging.
-O2
Optimize even more. GCC performs nearly all supported
optimizations that do not involve a space-speed tradeoff. The compiler
does not perform loop unrolling or function inlining when you specify
-O2. As compared to -O, this option increases both compilation time
and the performance of the generated code.
-O2 turns on all optimization flags specified by -O. It also turns
on the following optimization flags:
-fforce-mem
-foptimize-sibling-calls
-fstrength-reduce
-fcse-follow-jumps -fcse-skip-blocks
-frerun-cse-after-loop -frerun-loop-opt
-fgcse -fgcse-lm -fgcse-sm
-fdelete-null-pointer-checks
-fexpensive-optimizations
-fregmove
-fschedule-insns -fschedule-insns2
-fsched-interblock -fsched-spec
-fcaller-saves
-fpeephole2
-freorder-blocks -freorder-functions
-fstrict-aliasing
-falign-functions -falign-jumps
-falign-loops -falign-labels
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Eelco van Beek - IC&S
> Sent: Tuesday, October 28, 2003 12:34 PM
> To: [email protected]
> Subject: Re: [Dbmail] 100% cpu usage with dbmail-pop3d --
> SOLVED, for me
> at least
>
>
>
> -fomit-frame-pointer
> Don't keep the frame pointer in a register for functions that don't
> need one. This avoids the instructions to save, set up and restore
> frame pointers; it also makes an extra register available in many
> functions. It also makes debugging impossible on some machines.
>
> On some machines, such as the VAX, this flag has no effect,
> because the
> standard calling sequence automatically handles the frame pointer and
> nothing is saved by pretending it doesn't exist. The
> machine-description macro FRAME_POINTER_REQUIRED controls whether a
> target machine supports this flag. See Register Usage.
>
> Enabled at levels -O, -O2, -O3, -Os.
>
> As being told in the gcc man :)
>
> Eelco
>
>
> On 28-okt-03, at 10:20, Shih Ming-Wei wrote:
>
> > I don't think -O -O1 and -O2 impliciet -fomit-fram-pointer
> > not sure about -O3
> >
> > Ming-Wei
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] Behalf
> > > Of Eelco van Beek - IC&S
> > > Sent: Tuesday, October 28, 2003 9:37 AM
> > > To: [email protected]
> > > Subject: Re: [Dbmail] 100% cpu usage with dbmail-pop3d --
> > > SOLVED, for me
> > > at least
> > >
> > >
> > > I thought the stable version was compiled with -O which
> automatically
> > > enables the omission of frame pointer usage?
> > >
> > > Best regards,
> > >
> > > Eelco
> > >
> > > On 27-okt-03, at 23:08, Bret Baptist wrote:
> > >
> > > > On Friday 24 October 2003 5:35 am, Shih Ming-Wei wrote:
> > > >> hi,
> > > >>
> > > >> I have solve the 99% CPU usage on Linux/sparc systems that
> > > >> we are using, apparently changing CFLAGS from "-O2 -pipe" to
> > > >> "-march=v8 -mtune=v9 -O2 -pipe -fomit-frame-pointer" cahnges
> > > >> the CPU usage from 99% to max 1.8% (avg 0.4 %). So my
> > > >> conclusion is this is not a dbmail bug but dbmail must trigger
> > > >> some bug in platform/compiler/glibc,
> > > >>
> > > >> Just my 2 cents
> > > >>
> > > >>
> > > >> Hope this might help someone else
> > > >>
> > > >> Ming-Wei
> > > >
> > > > After more testing I have found that the important bit
> here is the
> > > > -fomit-frame-pointer. If I define that I don't get the
> > > excessive CPU
> > > > usage.
> > > > Is there any reason for not making this a standard compile
flag?
> > > >
> > > > I am running debian testing (sarge):
> > > >
> > > > Which has:
> > > >
> > > > gcc-3.3.1-2
> > > > kernel: 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686
> > GNU/Linux
> > > > libc6-2.3.2-7
> > > > mysql-client-4.0.13-3
> > > >
> > > > Anything else relevant?
> > > >
> > > > --
> > > > Bret Baptist
> > > > Systems and Technical Support Specialist
> > > > [EMAIL PROTECTED]
> > > > Internet Exposure, Inc.
> > > >http://www.iexposure.com
> > > >
> > > > (612)676-1946 x17
> > > > Web Development-Web Marketing-ISP Services
> > > > ------------------------------------------
> > > >
> > > >
> > > > Today is the tomorrow you worried about yesterday.
> > > >
> > > > _______________________________________________
> > > > Dbmail mailing list
> > > > [email protected]
> > > >https://mailman.fastxs.nl/mailman/listinfo/dbmail
> > > >
> > > _________________________
> > > E.J.A. van Beek
> > > ICT Manager
> > > IC&S
> > > T: +31 30 2322878
> > > F: +31 30 2322305
> > >
> > > PGP-key:
> > > www.ic-s.nl/keys/eelco.txt
> > >
> > > _______________________________________________
> > > Dbmail mailing list
> > > [email protected]
> > >https://mailman.fastxs.nl/mailman/listinfo/dbmail
> > >
> >
> _________________________
> E.J.A. van Beek
> ICT Manager
> IC&S
> T: +31 30 2322878
> F: +31 30 2322305
>
> PGP-key:
> www.ic-s.nl/keys/eelco.txt
>
> _______________________________________________
> Dbmail mailing list
> [email protected]
>https://mailman.fastxs.nl/mailman/listinfo/dbmail
>
_________________________
E.J.A. van Beek
ICT Manager
IC&S
T: +31 30 2322878
F: +31 30 2322305
PGP-key:
www.ic-s.nl/keys/eelco.txt
