From: kaih@khms.westfalen.de (Kai Henningsen)
To: gcc@gcc.gnu.org
Subject: Re: Optimizing of explicit temporary storage
Date: Wed, 13 Oct 2004 10:47:00 -0000 [thread overview]
Message-ID: <9IlO2StHw-B@khms.westfalen.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0410122302530.31127-100000@nondot.org>
sabre@nondot.org (Chris Lattner) wrote on 12.10.04 in <Pine.LNX.4.44.0410122302530.31127-100000@nondot.org>:
> On Tue, 12 Oct 2004, Daniel Berlin wrote:
>
> > >> Yes, but that's rather a different situation due to the nature of
> > >> Scheme.
> > >>
> > >> In C, even given just:
> > >>
> > >> (void) malloc(16);
> > >>
> > >> it would be surprising to most programmers to optimize away the call
> > >> because malloc *does* have side-effects on real systems. For example,
> > >> on UNIX, it is likely to call sbrk, which result in observable changes
> > >> in the process state.
> > >
> > > Well, yes, but
> > >
> > > int x[65536];
> > >
> > > also results in observable changes in the process state, and we don't
> > > hesitate to optimise it away.
> >
> > I believe LLVM actually does all kinds of promotion that ends up removing
> > malloc calls. Maybe i'm just misremembering.
>
> Yes, LLVM deletes dead malloc calls and does other things as well. The C
> spec defines the behavior of malloc/free, and from this description I
> believe that it is safe to do this (e.g. C99 second 7.20.3). Note,
> however, that Mark's point above about calling sbrk is beyond the
> standard: conformant programs can't know anything about sbrk.
Especially as that is strictly an internal library design decision: there
are certainly implementations that, say, use mmap() instead, and leave
sbrk() alone.
MfG Kai
next prev parent reply other threads:[~2004-10-13 7:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-10 21:51 Richard Guenther
2004-10-11 4:34 ` Mike Stump
2004-10-11 7:11 ` Richard Guenther
2004-10-12 7:38 ` Mark Mitchell
2004-10-12 8:40 ` Florian Weimer
2004-10-12 9:37 ` Mark Mitchell
2004-10-12 11:59 ` Robert Dewar
2004-10-12 12:19 ` Mark Mitchell
2004-10-12 13:10 ` Robert Dewar
2004-10-12 19:44 ` Mike Stump
2004-10-13 2:27 ` Geoffrey Keating
2004-10-13 3:42 ` Daniel Berlin
2004-10-13 9:18 ` Chris Lattner
2004-10-13 10:47 ` Kai Henningsen [this message]
2004-10-13 13:22 ` Daniel Berlin
2004-10-13 16:06 ` Chris Lattner
2004-10-13 11:45 ` Nick Ing-Simmons
2004-10-13 13:02 ` Giovanni Bajo
2004-10-13 13:12 ` Nick Ing-Simmons
2004-10-14 4:21 ` Mike Stump
2004-10-12 9:02 ` Kai Henningsen
2004-10-12 19:36 ` Mike Stump
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9IlO2StHw-B@khms.westfalen.de \
--to=kaih@khms.westfalen.de \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).