[Bug middle-end/31528] Inlining with -Os increases code size

[j at uriah dot heep dot sax dot de]

------- Comment #6 from j at uriah dot heep dot sax dot de  2007-04-10 17:15 -------
(In reply to comment #5)

> Inlining decisions are based on heuristics. What works for one
> target may not work quite as well for another. In this case, it
> seems that for AVR the heuristics are not the best.  You can tune
> the heuristics for this target and let the target options override
> the default heuristics parameters.

But what if *all* targets appear to suffer from pessimization?  I
think it cannot be called a bug of a particular target then.

Just for a completely different test, I compiled a GCC 4.1.1 (since I
had that source code around here) for a sparc64 target.  The results
support those of avr and i386:

% /tmp/sparc64/bin/sparc64-unknown-linux-gcc -Os -c bug66690.c
% /tmp/sparc64/bin/sparc64-unknown-linux-size bug66690.o
   text    data     bss     dec     hex filename
    212       0       0     212      d4 bug66690.o
% /tmp/sparc64/bin/sparc64-unknown-linux-gcc -Os -fno-inline -c bug66690.c
% /tmp/sparc64/bin/sparc64-unknown-linux-size bug66690.o
   text    data     bss     dec     hex filename
    124       0       0     124      7c bug66690.o

So is there a *single* target where inlining on that code would really
save space?  In all cases so far, the -fno-inline code saved a
dramatical amount of space, compared to the default -Os version.


Also, as you mention the target code has a chance to tune this (and I
know there are a lot of complaints from AVR users about pessimizations
caused by GCC 4.x, compared to 3.x), can you give me a hint about
where to look for these knobs?  I might give it a try to see whether I
can find a more optimal set of parameters.


-- 

j at uriah dot heep dot sax dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528