User: Password:
|
|
Subscribe / Log in / New account

Linux kernel design patterns - part 2

Linux kernel design patterns - part 2

Posted Jun 14, 2009 9:20 UTC (Sun) by nix (subscriber, #2304)
In reply to: Linux kernel design patterns - part 2 by jlokier
Parent article: Linux kernel design patterns - part 2

Yeah, I suppose you could do that. There'd be constraints on the form of
the fragment, though: basically it'd have to be an expression.

With the statement-expression extension you *might* be able to do
something more than one expression long, but you're really playing in
areas where that extension hasn't been tested by that point, so who knows
if it'll work. (Well, I suppose I could try it.)


(Log in to post comments)

Linux kernel design patterns - part 2

Posted Jun 15, 2009 15:17 UTC (Mon) by madscientist (subscriber, #16861) [Link]

If you're willing to write your code for GNU C only you can use the GCC extension allowing statements and declarations as expressions to make this much simpler. see section 5.1 "Statements and Declarations in Expressions" in the chapter "C Extensions" in the GCC manual.

This lets you have a much more complex "expressions"... at the expense of portability.

Linux kernel design patterns - lack of red/black tree search function

Posted Jun 20, 2009 19:47 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

... or guaranteed function cloning and cross-module inlining ...

I don't think it's cross-moduleness or variable-argumentness that make the common search function slow. It's the function pointer.

Does gcc inline even a locally defined used-once function when you call it via a constant function pointer? Didn't used to.

Linux kernel design patterns - lack of red/black tree search function

Posted Jun 21, 2009 22:26 UTC (Sun) by nix (subscriber, #2304) [Link]

No, it doesn't, but a sufficiently clever compiler could. The key is the
cross-module inlining.

(Even there, you'd be in trouble if the function doing the call was in a
different shared library than the caller. I don't see any way to fix
that.)

Linux kernel design patterns - lack of red/black tree search function

Posted Jun 21, 2009 22:46 UTC (Sun) by giraffedata (subscriber, #1954) [Link]

The key is the cross-module inlining.

Why is that the key? The pointed-to function would be in the main .c file and the library function that takes the function pointer as its argument would be in an included .h file like all the other functions we like to have inlined.

Linux kernel design patterns - lack of red/black tree search function

Posted Jun 22, 2009 22:21 UTC (Mon) by nix (subscriber, #2304) [Link]

Yes: and if the compiler was sufficiently clever, and all the .c files in
the application were presented to it at once, it would recognise instances
of this function that were frequently called with a particular function
pointer and clone a variant of that function that had that function
inlined into it: said variant would then get used only by the particular
call site in question.

This is way beyond what, say, GCC can do now, but is not disallowed nor
impossible to implement.

Linux kernel design patterns - lack of red/black tree search function

Posted Aug 22, 2009 15:32 UTC (Sat) by quotemstr (subscriber, #45331) [Link]

-fwhole-program


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds