------- 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
