This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining Improvements
Mark Mitchell wrote:
> I'm actually quite surprised that the tree-based inlining has made as
> much a difference (in the quality of the generated code) as it has in
> some cases. Some MIPS benchmarks one of our customers had now run
> twice as quickly -- somehow, the new inliner is making it easier for
> the back-end to do its job, at least in some situations.
I'm not surprised. I long ago complained that the "inline function is
as fast as a macro claim" was totally bogus.
With tree-based inlining changes hopefully the claim will finally
reflect reality.
Just recently I noticed that in an inline (C) function,
__builtin_constant_p was returning 1 just fine. But in a nested inline
function, it was not. Perhaps the large expression was too much for the
constant folder after RTL inlining, and it gave up.
Presumably if __builtin_constant_p is not reflecting constantness even
in some simple cases due to RTL inlining, early code generation
decisions based on "is this a constant" are also assuming "no".
Perhaps this gives some clue as to the kind of transformation the back
end should have been doing all along to do good RTL-based inlining? I
would not be surprised if such a transformation would be effective on
other kinds code too.
I look forward to seeing if tree inlining gives better
__builtin_constant_p results.
-- Jamie