<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 3:13 PM, David Turnbull via swift-users &lt;<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Fri, Dec 18, 2015 at 2:31 PM, Janosch Hildebrand via swift-users <span dir="ltr" class="">&lt;<a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a>&gt;</span> wrote:<br class=""><div class="gmail_quote"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">You will also want to have this code in the same module that is using this type.</div><div class="">If you're using these types from another module you're limited to unspecialized generics which are (unsurprisingly) very slow.</div></div></blockquote><div class=""><br class=""></div></span><div class="">This is becoming clear. Hopefully these patterns can be optimized across modules eventually. It's easy enough to write a pre-processor that expands the generics into four specializations. But it doesn't solve everything so not a priority.</div></div></div></div></div></div></div></blockquote><div><br class=""></div><div>I know that cross-module whole-program optimization is a long term goal for the build system; at what priority, I'm not sure. We do have some totally not-ready-for-primetime functionality for cross-module inlining and optimization that's used by the standard library and overlays; these libraries use special flags to serialize SIL bytecode into the module file. You can poke around the cmake files to see how the stdlib is built, though you're off the supported path if you try to mimic it. Since you're going down the code generation path already, though, you might also take a peek at the guts of the `simd` overlay:</div><div><br class=""></div><div><a href="https://github.com/apple/swift/blob/master/stdlib/public/SDK/simd/simd.swift.gyb" class="">https://github.com/apple/swift/blob/master/stdlib/public/SDK/simd/simd.swift.gyb</a></div><div><br class=""></div><div>Though there isn't a portable `simd` module supporting it on Linux, it shows how LLVM vector types are exported as Swift builtins that can be used to implement vector types in terms of machine SIMD types.</div></div><br class=""><div class="">-Joe</div></body></html>