[swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Johannes Weiß]

Hi Slava,

> On 22 Dec 2017, at 7:13 am, Slava Pestov <spestov at apple.com> wrote:
> 
> Hi Johannes,
> 
> Thanks for reviewing this proposal!
> 
>> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> The library I'm working on will presumably never have stable ABI as you'd naturally build it with your application. However we also don't want to miss on the cross-module optimisation & specialisation and I suspect there are quite a few (mostly open-source) libraries in the same space. I'm pretty sure everybody would just end up littering their code with @abiPublic/@inlinable (or the @available(...) syntax Chris Lattner proposed) without actually meaning that.
>> 
>> Summing up: I think this feature is crucial but shouldn't come without a compiler "where all declarations become implicitly @inlinable, and all private and internal declarations become @abiPublic". I really don't want to litter the code with attributes that aren't what I mean. (basically `swift build --global-resilience-domain`) Having this compiler mode also makes these attributes IMHO really niche and therefore I can only sympathise with's Chris' sentiment to not litter the global attribute namespace.
> 
> I agree that a ‘completely non-resilient’ compiler mode would be great when building libraries that are always shipped together, and I hope Swift gains such a feature one day, possibly built on top of the very infrastructure used to implement this proposal!

Cool. I just meant that the compiler mode and the public (as in non-underscored) attributes should go hand in hand to not tempt people into littering their code without thinking.


> However, the goal of this proposal is to formalize some language features that already exist and are used by the standard library. Clearly making everything fragile is a non-starter for the standard library in an ABI-stable world.

totally agree that these attributes are necessary, they should be in Swift as soon as we bike shedded the right name. But to prevent them from being placed everywhere without thinking I propose to introduce a compiler mode at the same time.
Performance testing is hard and takes time. So I'm pretty sure that as soon as one @abiPublic/@inlinable has proven to improve performance, library authors will just start putting them anywhere as there's no downside besides making the code harder to read.

What is the downside of bringing the attributes and the compiler mode at the same time. Am I massively underestimating the amount of work required for such mode?


> I do hope that this attribute is not abused in the manner in which you describe, but I’m not sure the potential for abuse is reason enough to not run the proposal — people are already using the underscored attribute today, risking source breakage and bugs due to insufficient test coverage in the future.

> 
>> C(++) as described in the proposal and Haskell (https://wiki.haskell.org/Inlining_and_Specialisation), where {-# INLINABLE myFunction #-} (quoting the docs) causes exactly two things to happens.
>> 
>> 	• The function's (exact) definition is included in the interface file for the module.
>> 	• The function will be specialised at use sites -- even across modules.
>> Note that [the Haskell compiler] GHC is no more keen to inline an INLINABLE function than any other.
> 
> Note that Swift’s compiler is the same — @inlinable does not influence optimizer decisions to inline or not.

Cool, that's what I suspected. Good to know that the Swift & GHC attributes are the same and even the name is :).
So we just need -fspecialise-aggressively 🤓.


> Also currently the proposal is implemented by binary serialization of the SIL IR, but nothing in it precludes serializing inlinable function bodies as source code in the future — in fact we are likely to go in that direction if we implement the proposed textual ‘stable’ module format.

Cool. Just to be sure I understand you correctly: Assuming your proposal gets implemented as proposed, a function that does _not_ have the @inlinable attribute it won't be specialised across modules, ever. Correct?


-- Johannes

> 
> Slava
>