<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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 Oct 7, 2016, at 9:25 PM, Andrew Trick <<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">I wonder whether it might make more sense for load [borrow] to be a different instruction.</div><div class="">There's a couple reasons for that first. The first is that it's the only load which introduces</div><div class="">a scope, which is a really big difference structurally. The second is that it's the only load</div><div class="">which returns a non-owned value, which will be a typing difference when we record</div><div class="">ownership in the type system.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I am fine with a load_borrow. If this is the only change left that you want can I just send out a proposal with that small change and start implementing. I am nervous about perfection being the enemy of the good (and I want to start implementing this weekend if possible *evil smile*).</div></div></div></div></blockquote></div><br class=""><div class="">There’s a lot in the proposal that makes sense to discuss for completeness but isn’t motivated by a particular need. Please separate functionality. We only need load [copy] at first right? When do those need to be promoted to load_borrow?</div></div></div></blockquote><div><br class=""></div><div>These are needed for the ARC optimizer to eliminate retain, release operations, i.e. a:</div><div><br class=""></div><div>%0 = load [copy] %x_ptr</div><div><br class=""></div><div>destroy_value %1</div><div><br class=""></div><div>=></div><div><br class=""></div><div>%0 = load [borrow] %x_ptr</div><div><br class=""></div><div>borrow_end(%0, %x_ptr)</div><div><br class=""></div><div>These constructs will be needed by engineers to update passes like ARC. By implementing such modifiers now, we can begin to implement support in the various passes for these new instructions via sil-opt/etc in parallel to other semantic ARC work.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> load [trivial] is an optimization, so that should follow a functionally complete implementation. </div></div></div></blockquote><div><br class=""></div><div>Yes you are correct that given that we are exploding the load [copy] in the eliminator, the trivial load is not *strictly* needed. But as soon as we start upgrading passes, we are going to want this. Again assuming that parallel work can be done, it makes sense to set the stage for optimizer work that will occur in parallel to further semantic ARC work.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> load [take] should definitely not exist until there’s some motivation.</div></div></div></blockquote><div><br class=""></div><div>If you look at the frontend, there are places where the frontend wants to emit a take. Unless we are willing to use unqualified loads for those cases (which we can not if we are trying to prove that no unqualified loads are emitted by the frontend), then we must have a load [take].</div><div><br class=""></div><div>Did I provide the motivation that you requested?</div><div><br class=""></div><div>Michael</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">-Andy</div></div></div></blockquote></div><br class=""></body></html>