<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 30, 2017, at 11:23 AM, Michael Gottesman via swift-dev &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">No. A parameter's convention is ABI. You don't want to change ABI related things like that via escape analysis since it means that as a function changes, due to the optimizer, the ABI can change =&gt;&lt;=. *BUT* recently Adam Nemet has added support for LLVM's opt remark infrastructure to Swift. Something like that /could/ provide suggestions when it is run that this might be a profitable parameter to change from +0 to +1 or vis-a-versa. Then the user could make that change via annotation. Keep in mind that this would most likely be an ABI breaking change.</span></div></blockquote></div><br class=""><div class="">ABI only matters at public entry points for ABI-stable binaries. We can do this sort of analysis freely within modules, or in a hypothetical multi-module-optimization mode.</div><div class=""><br class=""></div><div class="">-Joe</div></body></html>