On Sun, 11 Jan 2009, Andi Kleen wrote:
>
> The proposal was to use -fno-inline-functions-called-once (but
> the resulting numbers were not promising)
Well, the _optimal_ situation would be to not need it, because gcc does a
good job without it. That implies trying to find a better balance between
"worth it" and "causes problems".
Rigth now, it does sound like gcc simply doesn't try to balance AT ALL, or
balances only when we add some very version-specific random options (ie
the stack-usage one). And even those options don't actually make much
sense - yes, they "balance" things, but they don't do it in a sensible
manner.
For example: stack usage is undeniably a problem (we've hit it over and
over again), but it's not about "stack must not be larger than X bytes".
If the call is done unconditionally, then inlining _one_ function will
grow the static stack usage of the function we inline into, but it will
_not_ grow the dynamic stack usage one whit - so deciding to not inline
because of stack usage is pointless.
See? So "stop inlining when you hit a stack limit" IS THE WRONG THING TO
DO TOO! Because it just means that the compiler continues to do bad
inlining decisions until it hits some magical limit - but since the
problem isn't the static stack size of any _single_ function, but the
combined stack size of a dynamic chain of them, that's totally idiotic.
You still grew the dynamic stack, and you have no way of knowing by how
much - the limit on the static one simply has zero bearing what-so-ever on
the dynamic one.
So no, "limit static stack usage" is not a good option, because it stops
inlining when it doesn't matter (single unconditional call), and doesn't
stop inlining when it might (lots of sequential calls, in a deep chain).
The other alternative is to let gcc do what it does, but
(a) remove lots of unnecessary 'inline's. And we should likely do this
regardless of any "-fno-inline-functions-called-once" issues.
(b) add lots of 'noinline's to avoid all the cases where gcc screws up so
badly that it's either a debugging disaster or an actual correctness
issue.
The problem with (b) is that it's a lot of hard thinking, and debugging
disasters always happen in code that you didn't realize would be a problem
(because if you had, it simply wouldn't be the debugging issue it is).
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
