Re: Code size regressions, mainline+branch

[Jan Hubicka <jh at suse dot cz>]

> 	I assume that you are referring to x86 executable size.  Can you
> narrow the size regression any further?  Was binutils updated?

See the graphs. Almost all binaries of spec tests grown up. The page
does not mention any configuration change, even when it sounds like
best explanation. I will double check this.
Perhaps someone updated the machine to new glibc, that can only explan
such a growth to me...
> 
> 	Nothing in the first list of patch should have any effect unless
> something strange is happening with unrolling sibling calls.  The second
> list of patches also includes a sibcall change.

The sibbling call change in unroll.c should not affect non-unroll-all-loops
code at all.  I was investigating an performance regression in gap caused by
that patch, as it changed the branch predictor to stop believing about sibbling
calls that they are noreturn calls in some cases correctly predicting them as
not taken.  This may change code size somehow, but only in peak.
> 
> 	The expand_expr change correctly makes the values assigned from
> the string sign-extended.  Is the x86 port somehow choosing a different,
> longer x86 instruction because it does not think the signed char fits in a
> byte?

Possibly, but I would expect opposite effect.  I will check this as well.

Honza
> 
> David