On 11/28/24 7:57 AM, Jan Hubicka wrote:
I think a 4 state flag { never_inline, default, auto_inline, always_inline }
would be fine. The question is how to call the macro(s) and values
and how to merge those from different decls and what we do currently
e.g. for noinline, always_inline, on the s
>
> I think a 4 state flag { never_inline, default, auto_inline, always_inline }
> would be fine. The question is how to call the macro(s) and values
> and how to merge those from different decls and what we do currently
> e.g. for noinline, always_inline, on the same or on different decls
> of t
On Thu, 28 Nov 2024, Jakub Jelinek wrote:
> On Thu, Nov 28, 2024 at 01:03:01PM +0100, Richard Biener wrote:
> > > I think auto_inline and inline would be just confusing, even in the
> > > negative
> > > forms. We actually "auto-inline" even functions not declared inline, just
> > > with differen
On Thu, Nov 28, 2024 at 01:03:01PM +0100, Richard Biener wrote:
> > I think auto_inline and inline would be just confusing, even in the negative
> > forms. We actually "auto-inline" even functions not declared inline, just
> > with different heuristics.
>
> But inline __attribute__((feeble_inline
On Thu, 28 Nov 2024, Jakub Jelinek wrote:
> On Thu, Nov 28, 2024 at 11:23:02AM +0100, Richard Biener wrote:
> > Sorry for chiming in only late - to me this shows that the desire to inline
> > a function more than another function, currently identified as
> > DECL_DECLARED_INLINE_P overlaps with fr
On Thu, Nov 28, 2024 at 11:23:02AM +0100, Richard Biener wrote:
> Sorry for chiming in only late - to me this shows that the desire to inline
> a function more than another function, currently identified as
> DECL_DECLARED_INLINE_P overlaps with frontend semantic differences.
> But don't we reflect
On Thu, Nov 14, 2024 at 5:03 PM Jakub Jelinek 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)
> heavi
On Thu, 14 Nov 2024, Jakub Jelinek wrote:
> This patch introduces a new attribute for weaker inline semantics (basically
> it behaves as inline for the FE/debug info purposes, just for the
> optimization decisions acts as if it wasn't explicitly inline); I haven't
> used weak_inline for the attrib
> > 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_a
On Fri, 15 Nov 2024 at 12:02, Jakub Jelinek wrote:
>
> On Fri, Nov 15, 2024 at 11:25:00AM +, Jonathan Wakely wrote:
> > On Thu, 14 Nov 2024 at 18:16, Jan Hubicka wrote:
> > >
> > > > Hi!
> > > >
> > > > The inlining heuristics uses DECL_DECLARED_INLINE_P (whether a function
> > > > has been e
On Fri, Nov 15, 2024 at 11:25:00AM +, Jonathan Wakely wrote:
> On Thu, 14 Nov 2024 at 18:16, Jan Hubicka 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++
> >
On Thu, 14 Nov 2024 at 18:16, Jan Hubicka 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)
>
On Thu, Nov 14, 2024 at 08:38:38PM +0100, Jan Hubicka wrote:
> Concerning the other uses outside of inliner:
> - tree_inlinable_function_p and expand_call_inline check it to warn. We
>could silence the wraning via NO_INLINE_WRANING flag.
I know and initially I've even had that flag set in c-
>
> If it is in ipa_fn_summary, where would I do the lookup_attribute?
It is constructed in ipa-fnsummary.cc:analyze_function and then needs to
be duplicated by the duplicate hooks
>
> Anyway, looking at the spots where I've used DECL_OPTIMIZABLE_INLINE_P
> (agree it is a bad name), I think tree_
On Thu, Nov 14, 2024 at 07:07:48PM +0100, Jan Hubicka 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 def
> > +/* Nonzero if inlining should prefer inlining this function.
> > + Shorthand for DECL_DECLARED_INLINE_P && !DECL_FEEBLE_INLINE_P. */
> > +#define DECL_OPTIMIZABLE_INLINE_P(NODE) \
> > + (DECL_DECLARED_INLINE_P (NODE) && !DECL_FEEBLE_INLINE_P (NODE))
>
> We have 10 bits left, but it would
> 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.
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 cas
18 matches
Mail list logo
