On Tue, 29 Oct 2013, Mike Stump wrote: > On Oct 29, 2013, at 5:43 AM, Richard Sandiford <rsand...@linux.vnet.ibm.com> > wrote: > > Richard Biener <rguent...@suse.de> writes: > >> > >> I think the cases Mike added should only be enabled when we can figure > >> them out at compile-time, too. > > > > Well, the idea with most of these functions was to handle the simple > > "everything is one HWI" cases inline. > > Yes. The idea is that 99.99% of all cases are 1 HWI or less, > dynamically. By inlining and doing those cases inline, provided the > code is relatively small, seemed like a win. This win comes at the cost > of duplicative code in the wider path, as it checks the precision/length > as well, but slowing down those cases seemed reasonable with respect to > how infrequent we expect them. Now, if the slow path code is the same > speed as the inline code would have been, certainly the duplication just > hurts. This is why I was posting the code fragments for the fast path > case. I was aiming for the fast path to be really nice to help ensure > that we don't don't slow down compiles on narrow code any.
Handling the len == 1 case inline is fine, just don't add too many fast special cases (mixed len == 1, len > 1, special known extended cases, etc.) that are not decidable at compile-time as branchy code is both hard to optimize, and puts load on I-cache and the branch predictor. Richard.
