>I need functions inlined if they're dead-ends, or call other functions
>and return the foreign result without further calculation. I.e. they
>don't need to save and restore registers because they're not using any.
>That's about a 3-4 times speedup win for me (my compiler-compilers ..).
Wow. 3-4 times speedup over what? gcc -O5 ?
Your work sounds interesting.
>I produce lots of short functions from expression analysis. "a+b+c"
>might generate 6 functions, one for each subexpression and one for each
>referent.
>
>If gcc can't detect the (tail-recursion at worst) case its dataflow
>analysis is fundamentally broken. Given that it is broken, possibly
>only for the assembler case (?? - isn't gcc using its
>internal representation at this point?) it should at least be able to say
>"i'm not sure" and fallback to saving/restoring registers.
>
>> Note that this is not just a workaround for a bug. The fact is, that with
>
>As phrased, it is! It looks more like one should just stop gcc being so
>optimistic when it's data analysis doesn't warrant it.
>
No it's not. It's a reflection of reality. As I mis-understand it Dataflow
works perfectly, IF you have infinite resources.
>> small-register-set, inlining functions is not likely to be all that big of
>> a win (and is often a loss due to register allocation pressure) unless the
>> function is _really_ small or for some special cases - and in both cases
>> hopefully the function is marked inline already by the knowledgeable user.
>
>The knowledgeable user relies on the knowledgable compiler here. All
>studies show that hand-optimizing code is a waste of effort 99.99% of
>the time, not least because it's unmaintainable. Experience says so
>too. I've regretted every "optimization" I've ever done.
>
(Wow. What a "straight line".)
Your compiler compiler compilers work on a functional model? A one-stack
machine? How does inlining a "function" effect registers? I can see it
saving a call and a return. A function in this case has to save it's
whole state too? i.e. it's really a subroutine? Where? On a stack frame
on the CPU return stack?
I don't understand this stuff, but I do know that there are places
where extremely knowledgeable programmers and engineers want nothing
so-ever to do with automated optimization. The prospering Forth world,
where "inlining functions" is irrelevant, due in part to the 2-stack
machine model eliminating the tendency to pretend subroutines are
functions. Pinhole optimization does well on Forths, but only when
building the system fundamentals, not when writing apps.
>Peter
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>
3 4 * .
12 OK
Rick Hohensee http://cqi.com/~humbubba
colorg on EFnet IRC #linux chanop
cLIeNUX xart kandinski cycluphonics ratioles Md., USA
This is your brain on colorg --> (@#*%@#() <---~~~_()()(
Any questions?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/