In gcc-3.3, the -finline-limit had little effect. You could turn
that knob all you wanted, and code size didn't change much. In
gcc-4.0, the inliner's both better, and (I think) the meaning of the
number with -finline-limit changed. As a result, the -finline-limit
has a much bigger effec
>
> The used compile options are:
>
> ...
> -ftree-vectorize
I don't know how much vectorization takes place in your code, but
vectorization would currently greedily increase code size (i.e. without
trying to estimate when it is profitable). One way to avoid some of the
code size growth during vec
On 12/7/05, Andreas Killaitis <[EMAIL PROTECTED]> wrote:
> Hello list,
>
> I have a question concerning the size of the code generated by gcc
> 4.0.2 and 4.1.
> We talk about a C++ app with many smaller (30k) or larger (4M) C++
> libraries.
> Being happy the size of those libs decreased by about 20
On Dec 6, 2005, at 5:25 PM, Andreas Killaitis wrote:
Obviously I've been expressing me not very clear. I don't care for
code size (well, at least not soo much), speed is what counts, and
speed is what I get. I was just wondering why the code size has
increased with the new gcc version. An in
Am 07.12.2005 um 02:14 schrieb Mike Stump:
On Dec 6, 2005, at 4:35 PM, Andreas Killaitis wrote:
-finline-limit-10
This and wanting a small size are kinda incompatible. There might
be smaller values of n that will shrink the code, and yet still
give you the performance you seem to wa
On Dec 6, 2005, at 4:35 PM, Andreas Killaitis wrote:
-finline-limit-10
This and wanting a small size are kinda incompatible. There might be
smaller values of n that will shrink the code, and yet still give you
the performance you seem to want.
Andreas Killaitis <[EMAIL PROTECTED]> wrote:
> I was now astonished
> that my tests with gcc 4.1 showed that the library size has been
> grown by about 10%.
> The used compile options are:
>
> [...]
> -O3
Don't expect GCC to optimize code size at -O3. -O3 means -O2 *and* inline as
much as it ma
