[swift-evolution] Pitch: Cross-module inlining and specialization

[Taylor Swift]

On Wed, Oct 4, 2017 at 11:44 AM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> On Oct 3, 2017, at 9:56 PM, Chris Lattner <clattner at nondot.org> wrote:
>
>
> On Oct 3, 2017, at 9:50 AM, Joe Groff <jgroff at apple.com> wrote:
>
>
>
> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> We have discussed adding a "versioned @inlinable" variant that preserves
> the public entry point for older clients, while making the declaration
> inlinable for newer clients. This will likely be a separate proposal and
> discussion.
>
> 5) It eliminates this complexity.
>
>
> It wouldn't avoid the complexity, because we want the "non-ABI,
> always-emit-into-client" behavior for the standard library. For the
> soon-to-be-ABI-stable libraries where @inlinable even matters, such as the
> standard library and Apple SDK overlays, there's pretty much perfect
> overlap between things we want to inline and things we don't want to take
> up binary space and ABI surface in binaries, so the behavior Slava proposes
> seems like the right default.
>
>
> I disagree.  The semantics being proposed perfectly overlap with the
> transitional plan for overlays (which matters for the next few years), but
> they are the wrong default for anything other than overlays and the wrong
> thing for long term API evolution over the next 20 years.
>
>
> I disagree with this. 'inline' functions in C and C++ have to be backed by
> a symbol in the binary in order to guarantee function pointer identity, but
> we don't have that constraint. Without that constraint, there's almost no
> way that having a fallback definition in the binary is better:
>
> - It becomes an ABI compatibility liability that has to be preserved
> forever.
> - It increases binary size for a function that's rarely used, and which is
> often much larger as an outlined generic function than the simple operation
> that can be inlined into client code. Inlining makes the most sense when
> the inlined operation is smaller than a function call, so in many cases the
> net dylib + executable size would increase.
> - It increases the uncertainty of the behavior client code sees. If an
> inlinable function must always be emitted in the client, then client code
> *always* gets the current definition. If an inlinable function calls into
> the dylib when the compiler chooses not to inline it, then you may get the
> current definition, or you may get an older definition from any published
> version of the dylib. Ideally these all behave the same if the function is
> inlinable, but quirks are going to be inevitable.
>
> -Joe
>
>
> -Chris
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
i’m just tryna follow along here && this is probably a dumb question, but
is it possible for a generic function to be emitted as a set of specialized
functions into the client, but not inlined everywhere? It can be the case
where a large generic function gets slowed down by the large number of
generic operations inside it but it doesn’t make sense for it to be inlined
completely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171004/bb885ea4/attachment.html>