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 frontend semantic differences.
> > But don't we reflect those semantic differences into the IL (via linkage,
> > symtab details) already?
>
> After handling it in the FE, yes, we do. We still want
> DECL_DECLARED_INLINE_P also e.g. for debug info generation.
>
> > So what would remain is a way for the user
> > to distinguish between auto-inline (we have the corresponding -auto
> > set of --params) and inline-inline. The middle-end interface after your
> > change, where DECL_DECLARED_INLINE_P means inline-inline
> > unless !DECL_OPTIMIZABLE_INLINE_P looks a bit awkward.
> >
> > Rather than clearing DECL_DECLARED_INLINE_P I'd suggest to
> > split both completely and turn DECL_DISREGARD_INLINE_LIMITS,
> > DECL_UNINLINABLE and auto-inline vs. inline-inline into a
> > multi-bit enum and only use that for inlining decisions (ignoring
> > DECL_DECLARED_INLINE_P for that purpose, but use that
> > and feeble_inline to compute the enum value).
>
> 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 the same function.
Well, the same question stands now, just that we can easily end up
with non-sensical flag combos like DECL_UNINLINABLE and
DECL_DISREGARD_INLINE_LIMITS set. The enum would get rid of such
nonsense and instead require to define how conflicting attributes
would merge (I'd say last wins, just like with command-line flags,
with possibly diagnosing the earlier ignored one).
DECL_INLINE_SETTING would be my proposed name for the enum,
the enum flags you proposed look good besides that I think
'default' is actually 'auto_inline' and 'inline' is the
auto-inline with stronger inline preference (previously
DECL_DECLARED_INLINE_P).
> > Note I've had to lookup what 'feeble' means - given we use -auto
>
> feeble was used in the meaning of synonym to weak, as I wrote,
> weak_inline could be confusing.
> Another possibility would be weaker_inline though, that one can't
> confuse with weak attribute.
Joseph already approved the feeble_inline name, so I can live with it.
>From the implementation side I'd have prefered to more easily
associate it with inline vs. auto-inline.
> > for --params I'd have chosen __attribute__((auto_inline)), possibly
> > "completed" by __attribute__((inline)) to mark a function as
> > wanting 'inline' heuristics but not 'inline' semantics.
>
> 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)) is exactly 'auto-inline', no?
I'm confused.
Richard.
