On Fri, Nov 15, 2024 at 11:25:00AM +0000, Jonathan Wakely wrote:
> On Thu, 14 Nov 2024 at 18:16, Jan Hubicka <hubi...@ucw.cz> wrote:
> >
> > > Hi!
> > >
> > > The inlining heuristics uses DECL_DECLARED_INLINE_P (whether a function
> > > has been explicitly marked inline; that can be inline keyword, or for C++
> > > also constexpr keyword or defining a function inside of a class
> > > definition)
> > > heavily to increase desirability of inlining a function etc.
> > > In most cases it is desirable, people usually mark functions inline with
> > > the intent that they are actually inlined.
> >
> > Reading the discussion on the PR, one of argument for adding new
> > attribute was that we should not make differnece between "constexr" and
> > "constexpr inline" since C++ stnadard says it is the same.
> >
> > We already do such difference between
> >
> > class foo
> > {
> > int bar () { }
> > inline int bar2 () { }
> > };
>
> We do?!?!
>
> Is this documented anywhere?
As I wrote in another mail, the only difference I'm aware of is
the DECL_NO_INLINE_WARNING_P flag, which is set on bar and not on bar2
in this case. That flag is used just for -Winline warning.
int baz (void *);
struct S {
int foo (int n) { return baz (__builtin_alloca (n)); }
inline int bar (int n) { return baz (__builtin_alloca (n)); }
};
int
baz (int n)
{
return S{}.foo (n) + S{}.bar (n);
}
We do warn with -O2 -Winline about not inlining bar, but not foo.
This was changed in PR18071.
Jakub
