On Thu, Aug 3, 2017 at 2:49 PM, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> My conclusion is that most of the problem here comes from the fact that:
> - sparse always inlines function marked as inline
> - and does so very early, before any optimizations (so the extra macro
> code is inlined 2044 times and need to be processed 2044 times).
Yeah, I think that's sadly fairly fundamental to how sparse inlining works.
Sparse inlines things on a tree level, but most optimizations and
simplifications are done on the SSA representation.
That very early inlining was actually a fairly big design decision
originally - at some point I actually wanted to allow sparse to have
inline functions act as untyped "templates" that it inlined, and that
had their types evaluated only within the context of being used.
I have this memory of that actually even working to some degree at
some point (ie you could leave arguments to inline functions untyped,
and they would take their type from the invocation). But that may have
been with special patches.
But yes, for this particular case it's apparently a horrible choice,
exactly because it inlines very early before any actual evaluation of
anything.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
