This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]