Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Mitchell Blank Jr]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/