From: David Miller <davem@davemloft.net>
To: mpatocka@redhat.com
Cc: helge.hafting@aitel.hist.no, sparclinux@vger.kernel.org,
linux-kernel@vger.kernel.org, gcc@gcc.gnu.org
Subject: Re: [10 PATCHES] inline functions to avoid stack overflow
Date: Wed, 25 Jun 2008 15:09:31 -0700 (PDT) [thread overview]
Message-ID: <20080625.150931.182895076.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0806250843460.20379@engineering.redhat.com>
From: Mikulas Patocka <mpatocka@redhat.com>
Date: Wed, 25 Jun 2008 08:53:10 -0400 (EDT)
> Even worse, gcc doesn't use these additional bytes. If you try this:
>
> extern void f(int *i);
> void g()
> {
> int a;
> f(&a);
> }
>
> , it allocates additional 16 bytes for the variable "a" (so there's total
> 208 bytes), even though it could place the variable into 48-byte
> ABI-mandated area that it inherited from the caller or into it's own
> 16-byte padding that it made when calling "f".
The extra 16 bytes of space allocated is so that GCC can perform a
secondary reload of a quad floating point value. It always has to be
present, because we can't satisfy a secondary reload by emitting yet
another reload, it's the end of the possible level of recursions
allowed by the reload pass.
GCC could be smart and eliminate that slot when it's not used, but
such a thing is not implemented yet.
It would also require quite a bit of new code to determine cases
like you mention above, where the incoming arg slots from the
caller are unused, assuming this would be legal.
And that legality is doubtful. We'd need to be careful because I
think the caller is allowed to assume that those slots are untouched
by the callee, and thus can be assumed to have whatever values the
caller put there even after the callee returns.
next prev parent reply other threads:[~2008-06-25 22:09 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-24 5:54 Mikulas Patocka
2008-06-24 5:55 ` [1/10 PATCH] inline __queue_work Mikulas Patocka
2008-06-24 5:56 ` [2/10 PATCH] inline inline-generic_writepages.patch Mikulas Patocka
2008-06-24 5:57 ` [3/10 PATCH] inline wake_up_bit Mikulas Patocka
2008-06-25 14:17 ` Denys Vlasenko
2008-06-25 14:36 ` Mikulas Patocka
2008-06-25 15:24 ` Denys Vlasenko
2008-06-25 16:01 ` Mikulas Patocka
2008-06-25 20:37 ` Denys Vlasenko
2008-06-26 0:28 ` David Miller
2008-06-26 3:35 ` Denys Vlasenko
2008-06-26 4:18 ` David Miller
2008-06-26 18:22 ` Pavel Machek
2008-06-25 22:23 ` David Miller
2008-06-25 22:30 ` David Miller
2008-06-24 5:57 ` [4/10 PATCH] inline __wake_up_bit Mikulas Patocka
2008-06-24 5:58 ` [5/10 PATCH] inline __wake_up Mikulas Patocka
2008-06-24 5:59 ` [6/10 PATCH] inline default_wake_function Mikulas Patocka
2008-06-24 5:59 ` [6/10 PATCH] inline autoremove_wake_function Mikulas Patocka
2008-06-24 6:01 ` [8/10 PATCH] inline filemap_fdatawrite Mikulas Patocka
2008-06-24 6:01 ` [9/10 PATCH] inline dm-kcopyd-inline-wake.patch Mikulas Patocka
2008-06-24 6:03 ` [10/10 PATCH] inline dispatch_job Mikulas Patocka
2008-06-24 6:06 ` [PATCH] limit irq nesting Mikulas Patocka
2008-06-24 7:01 ` [10 PATCHES] inline functions to avoid stack overflow Ingo Molnar
[not found] ` <486216E7.8000002@aitel.hist.no>
2008-06-25 12:53 ` Mikulas Patocka
2008-06-25 22:09 ` David Miller [this message]
2008-06-26 6:32 ` Bart Van Assche
2008-06-26 9:06 ` David Miller
2008-07-02 4:39 ` Mikulas Patocka
2008-07-02 4:45 ` David Miller
2008-07-03 21:12 ` Mikulas Patocka
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=20080625.150931.182895076.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=gcc@gcc.gnu.org \
--cc=helge.hafting@aitel.hist.no \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=sparclinux@vger.kernel.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
all inboxes | Powered by JetHome®