On Mon, Jan 07, 2008 at 10:21:47AM +0200, Ilpo Järvinen wrote: > > Unexpected enough, even this logic seems to fail in a way with my gcc, I'm > yet to study it closer but it seems to me that e.g., uninlining only once > called tcp_fastretrans_alert is worth of at least 100 bytes (note that > it's not inlined by us, gcc did it all by itself)! Otherwise I'd fail to > understand why I got -270 bytes from uninlining tcp_moderate_cwnd which is > only 57 bytes as unlined with three call sites.
Yeah I've studied this effect over the years in my maintainence of the dash shell where size is paramount :) On x86-32 due to the scarcity of registers local variables often end up on the stack. In that case gcc will usually refer to them via %ebp or %esp. It just so happens that if the offset is within 128 bytes of the base register then the instruction can encode the offset with just a single byte. However, if it exceeds 128 bytes the instruction will take 4 bytes to encode the offset. Since bigger functions are more likely to go over that threshold, this explains some instances where uninlining ends up being bigger. There are other similar issues, such as the branch offset which also goes from 1 byte to 4 when you go over 128 bytes. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
