<div dir="ltr">On Fri, Jan 13, 2017 at 7:51 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Thanks, that's very helpful. Yes, my question was more directed to those situations that can't be optimized away. It's good to know that the maximum total cost is an and and a shift, which is what it sounded like but wasn't made explicit.</blockquote><div><br></div><div>Oy, I misread your reply; the maximum total cost for a _masking_ shift is two very cheap instructions; the maximum total cost for a _smart_ shift is potentially higher. I know it's unrealistic, but what will we be looking at when it comes to this:</div><div><br></div><div>```</div><div><div>func foo() -> UInt32 {</div><div> return arc4random() >> arc4random()</div><div>}</div></div><div>```</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_quote"><div dir="ltr">On Fri, Jan 13, 2017 at 17:25 Stephen Canon <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> On Jan 13, 2017, at 5:14 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail-m_846650756316354165gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail-m_846650756316354165gmail_msg">
><br class="gmail-m_846650756316354165gmail_msg">
> [Resending to list with original message removed for length.]<br class="gmail-m_846650756316354165gmail_msg">
><br class="gmail-m_846650756316354165gmail_msg">
> This is fantastic. Glad to see it take shape. Very neat and insightful to have trailingZeros on BinaryInteger but leadingZeros on FixedWidthInteger. A couple of questions on smart shifts: What is the performance penalty as compared to the existing operators? Beyond performance, what are the implications for migrating existing bit twiddling algorithms written in Swift 3?<br class="gmail-m_846650756316354165gmail_msg">
<br class="gmail-m_846650756316354165gmail_msg">
Hi Xiaodi —<br class="gmail-m_846650756316354165gmail_msg">
<br class="gmail-m_846650756316354165gmail_msg">
I don’t want to speak for Max and Dave, but I think I can provide some insight for your questions about shifts.<br class="gmail-m_846650756316354165gmail_msg">
<br class="gmail-m_846650756316354165gmail_msg">
First, the overwhelming majority of shifts have a compile-time-constant RHS. For these cases, there’s no performance change (except that the smart shifts may be able to optimize away the entire expression if the shift is overlarge).<br class="gmail-m_846650756316354165gmail_msg">
<br class="gmail-m_846650756316354165gmail_msg">
For smart shifts with non-constant right-hand sides, the compiler will frequently still be able to prove that the shift count is always positive or negative and less than word size (this handles a lot of the most common cases like normalizing an integer, reading from a bitstream, or shifting words of a bignum); again there’s no performance penalty.<br class="gmail-m_846650756316354165gmail_msg">
<br class="gmail-m_846650756316354165gmail_msg">
In the remaining cases where the compiler cannot bound the right-hand side, there will be some branches present; there may be a few regressions from these cases, but I expect most to be small (and the code simplifications are well worth it). Users can always use the masking shifts, which lower to single instructions for 32b and 64b integers types on Intel and arm64, and which are at worst an and and a shift (two very cheap instructions) on other architectures.<br class="gmail-m_846650756316354165gmail_msg">
<br class="gmail-m_846650756316354165gmail_msg">
Basically, I expect there to be no perf impact for almost all code, and that the perf impact is relatively easily mitigated when it does occur. This is an easy tradeoff for fully-defined and sensible operator behavior.<br class="gmail-m_846650756316354165gmail_msg">
<br class="gmail-m_846650756316354165gmail_msg">
– Steve</blockquote></div></div></div></blockquote></div><br></div></div>