>
> 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.
I was also thinking a bit of the name, but it seemed too late to jump in
:)
Generally inliner has the following modes
- noinline
- conservative inlining (driven by -auto limits)
- aggressive inlining (driven by -single limits)
- disregarding inline limits (inline when you can, former extern inline
of GNU C)
- always inline (error when you can not inlined, at least sometimes -
we included a design problem allowing always inline functions to have
address taken, be recursive or be exported since historically
always_inline was upgraded from disregarding to stronger
interpretation)
Moreover meaning of conservative and aggressive is sensitive to
optimization level and also can be overwritten by inline hints.
So if we go for multi stage flag we probably want to have those 5 levels
+ default option. There is also PR about switching inline limits (O2
wrt O3) which I am not sure how to fit into this picture.
-auto and -single names are historical and not very good. -single
predates me and -auto is my fault.
Perhaps the flags to switch conservative and aggresive inlining
be called somehting like inline_conservatively and inline_aggresively
or conservative_inline and aggressive_inline. feeble_inline is
conservative option...
Honza
>
> > 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.
>
> > 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.
>
> Jakub
>
