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>