Date: 27 Oct 2000 18:54:50 -0400 From: Randell Jesup <rjesup@wgate.com> To: Juha Saarinen <juha@saarinen.org> Cc: Michel Talon <michel@lpthe.jussieu.fr>, "freebsd-stable@FreeBSD.ORG" <freebsd-stable@FreeBSD.ORG> Subject: Re: "Malloc type lacks magic" show-stopper solved Message-ID: <ybupuklopxh.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Juha Saarinen's message of "Sat, 28 Oct 2000 11:19:37 %2B1300 (NZDT)" References: <Pine.LNX.4.21.0010281116220.16125-100000@vimfuego.saarinen.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Juha Saarinen <juha@saarinen.org> writes: >> things like PII's than for Athlon/Duron). Removing frame pointers for >> example can save a lot of memory traffic, > >With -fomit-frame-pointer? That doesn't seem to be possible -- if you try >that, you get an error message about "pg" (probably not the right name, >but I can't check that now) not being compatible with >-fomit-frame-pointer. True - profiling code hooks (-pg) aren't compatible with -fomit-frame-pointer. So? If I want to compile a version for profiling the kernel, I'll compile a version for that purpose. >> as can letting the compiler optimize away or merge locals. > >How would you do that, out of interest? The compiler says "look, this variable isn't used again before it's thrown away (or set to another value). I'll reuse the register/stack location it's stored in for another value". Typical result is that when debugging code optimized this way, "dead" variables display as garbage in a debugger. I suspect gcc does that optimization at the -O level. It may do more of it at -O2 or -O3. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybupuklopxh.fsf>