On Fri, Aug 12, 2005 at 10:35:33PM +0200, Jan Hubicka wrote:
> Unforutnately the actual size we want to limit is somewhat variable (for
> kernel it is pretty small, in usual case few hounderd K is probably good
> choice).
I disagree. If recusion is involved, even a few K may be unacceptable.
That
It could still be done, even if we inline.
There is nothing that prevents us from adding space to the stack
allocation only at that point, it's just not coded in gcc to do that.
...and take the stack alloc back after the inlined call is finished.
This is what the original example needs; it doesn
> You'd expect the attempt to grow the stack to be made only *after*
> keep_going hits zero.
Only if you thought you knew better than the compiler :)
> I'd rather not have the compiler presume
> certainty of a 10GB stack allocation, especially not if it's actually
> pretty unlikely.
It could
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, Aug 12, 2005 at 02:16:39PM -0700, Ian Lance Taylor wrote:
> > Mike Stump <[EMAIL PROTECTED]> writes:
> > > X can be run time selectable, OMF selectable, OS defined...
> >
> > No.
> >
> > Making the stack bigger by inlining is no di
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Aug 12, 2005 at 02:16:39PM -0700, Ian Lance Taylor wrote:
> Mike Stump <[EMAIL PROTECTED]> writes:
> > X can be run time selectable, OMF selectable, OS defined...
>
> No.
>
> Making the stack bigger by inlining is no different from making it
Mike Stump <[EMAIL PROTECTED]> writes:
> In general you'll want to understand how OSes allocate stack, and how
> the determine if an access is to the stack or not. The canonical
> unix way is to catch a fault, and if that fault is within X MB (8MB
> in years past) of the top of the stack, assume
On Aug 12, 2005, at 12:25 PM, Paul Koning wrote:
Mike> I think we should turn off inlining for functions > 100k stack
Mike> size. (Or maybe 500k, if you want).
Why should stack size be a consideration? Code size I understand, but
stack size doesn't seem to matter.
In general you'll want to
> > "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
>
> Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
> >> We had a situation come up here where things are like this
> >> (simplified, obviously):
> >>
> >> c() { char x[100]; }
>
> Mike> I think we should turn off inli
On Aug 12, 2005, at 4:00 PM, Dale Johannesen wrote:
Sometimes it matters, as in the original example:
c() { char x[100]; }
a() { b(); c(); }
b() { a(); c(); }
Actually in this case, x is removed so it does not matter at all.
This case though it does matter:
int f(int*); int g(void); in
On Aug 12, 2005, at 12:25 PM, Paul Koning wrote:
"Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
We had a situation come up here where things are like this
(simplified, obviously):
c() { char x[100]; }
Mike> I think we shou
> "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
>> We had a situation come up here where things are like this
>> (simplified, obviously):
>>
>> c() { char x[100]; }
Mike> I think we should turn off inlining for functions
On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
We had a situation come up here where things are like this
(simplified, obviously):
c() { char x[100]; }
I think we should turn off inlining for functions > 100k stack size.
(Or maybe 500k, if you want).
We had a situation come up here where things are like this (simplified,
obviously):
c() { char x[100]; }
a() { b(); c(); }
b() { a(); c(); }
c() is a leaf. Without inlining, no problem. WIth c() inlined into
a() and/or b(),
a few mutually recursive calls to a() and b() blow out the stack
13 matches
Mail list logo
