Messages in this thread | | | Date | Thu, 5 Jan 2006 16:50:04 -0800 | From | Mitchell Blank Jr <> | Subject | Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers |
| |
Linus Torvalds wrote: > Oh, but validatign things like "likely()" and "unlikely()" branch hints > might be a noticeably bigger issue.
I think the issues are somewhat intertwined.
For instance, assume you have code like:
if (some_function(skb)) { blah(); printk(KERN_WARN "bad packet...\n"); } else { process_skb(skb); }
Now just by annotating printk() as "rare" then gcc should be able to guess that the "if" is unlikely() without explicitly marking it as such since one of its paths calls a rare function and the other does not. If instead both paths called rare functions then the compiler could decide that the whole block is probably "rare" and optimize accordingly.
I haven't looked at gcc 4.1 yet so I don't know how sophisticated its "rare" promotion rules are yet but this is certainly the kind of thing the compiler should be able to handle.
So basically better inter-functional locality hints should also help intra-functional locality.
[from another message] > We don't have likely()/unlikely() that often, and at least in my case it's > partly because the syntax is a pain (it would probably have been better to > include the "if ()" part in the syntax - the millions of parenthesis just > drive me wild).
I actually did that in a project once (an "unlikely_if()" macro) It was not a good idea. The problem is that every syntax-highlighter knows that "if" is a keyword but you'd have to teach it about "unlikely_if". It was surprising how visually jarring having different pretty-printing for different types of "if" statements was. "if (unlikely())" looks much cleaner in comparison.
-Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |