This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [wide-int] More optimisations
- From: Mike Stump <mikestump at comcast dot net>
- To: Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>
- Cc: Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, zadeck at naturalbridge dot com
- Date: Tue, 29 Oct 2013 18:22:53 -0700
- Subject: Re: [wide-int] More optimisations
- Authentication-results: sourceware.org; auth=none
- References: <874n82rcpn dot fsf at talisman dot default> <alpine dot LNX dot 2 dot 00 dot 1310291318130 dot 11149 at zhemvz dot fhfr dot qr> <877gcwz1q8 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
On Oct 29, 2013, at 5:43 AM, Richard Sandiford <rsandifo@linux.vnet.ibm.com> wrote:
> Richard Biener <rguenther@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.