lkml.org 
[lkml]   [1997]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: a.out binaries that are 66% faster than ELF, problem found?
> i think we have the answer, as the same problem is causing unjustified
> stack overflows in the kernel. GCC is allocating lots of stack slots to
> pseudoregisters (correct me if i'm saying something stupid), and the
> optimization process removes 90% of them.

No, it allocates pseudoregisters for variables (unless they are volatile or
their address is taken) and if it can't get hard regs for them it allocates
stack slots during reload.

> But GCC doesnt 'compress' the stack after that.

> for example, aic7xxx_isr() has a real stack usage of 53 bytes,

There aren't only the variables at the start of the function. Look a bit
further down, somewhere in a local block they allocate a huge array. That's
where the stack usage comes from (yes, I looked at this too yesterday for a
different reason - frightens me because I happen to have a 2940).

BTW, it occurred to me that compiling the kernel with -finline-functions _may_
increase the probability of kernel stack overflows - say you have a function
which may get called recursively, and which (rarely) calls another small
function that uses lots of stack. If GCC were to inline the small function,
you'd have a much higher stack usage in the normal case.

> 2.5.8 2.7.2.1
> RC5_KEY_CHECK: RC5_KEY_CHECK:
> subl $12,%esp subl $304,%esp

Now that _is_ interesting.

[snip - more interesting stuff deleted]

> For the 'sparse stack problem' i dont know how hard it is to fix this in
> GCC, my feeling is that all the abstractions are already there to 'remap'
> stack slots, if yes then the fix should be easy. I'd sure play around with
> a few PGCC snapshots if such optimization would be implemented ;)

I guess you could implement something like this in PGCC, but I doubt you'd
get it into the "normal" gcc. There are apparently machines which can't handle
arbitrary offsets to sp/fp, which means that once register allocation is
complete (and only at that point do you know which stack slots you are using),
you can't safely change the offsets. I could be wrong, though.

Bernd

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.036 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site