This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -fobey-inline (was Re: gcc and inlining)
- From: dewar at gnat dot com (Robert Dewar)
- To: bernds at redhat dot com, dewar at gnat dot com
- Cc: gcc at gcc dot gnu dot org, geoffk at geoffk dot org, jbuck at synopsys dot com
- Date: Sun, 16 Mar 2003 10:30:31 -0500 (EST)
- Subject: Re: -fobey-inline (was Re: gcc and inlining)
> You've been arguing that the compiler will be smart enough to decide on
> a case-by-case basis whether inlining is profitable. To make such an
> informed decision, you surely need information about function sizes and
> execution frequencies, among several other things. If this information
> is available, then a mere hint becomes redundant [*] since you can deduce
> the necessary conditions algorithmically. OTOH, if such information is
> not available, then the compiler really has no business second-guessing
> the user.
I have argued nothing of the kind, please reread what I have written. What
I have said is that the compiler may have very good reasons in specific
cases which result in a decision not to inline a given function. In fact
you agree with this:
> within reason - I don't strongly object to not inlining
> functions that call alloca, for example
What makes you think that I disagree and expect this to be done
without reason?
> OTOH, if such information is
> not available, then the compiler really has no business second-guessing
> the user.
A clear case to second guess in the absence of inline always, is a case
in which inlining is known by the compiler to result in slower code
than not inlining.
or one in which it might be possible to inline, but it is just too much of
a pain in the neck to do so (the alloca case is in this category I think).
GNAT has an option to warn if a function is not inlined when it is requested
to be inlined, I think this is a useful (optional) warning.
> Let me remind you that we are discussing the effects of a change in
> behaviour of our C compiler. What Ada programmers do or don't do may be
> influenced by the behaviour of Ada compilers and might therefore not be
> entirely relevant.
I see no reason to think the Ada and C experiences should be different here,
other than that the Ada community has 20 years experience with this feature.
The intention and language in the relevant standards is essentially
identical in my view. If you think there is a big difference here, I think
the burden of proof is on you to show that.