From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26914 invoked by alias); 12 Jul 2012 01:45:07 -0000 Received: (qmail 26887 invoked by uid 22791); 12 Jul 2012 01:45:05 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta02.westchester.pa.mail.comcast.net (HELO qmta02.westchester.pa.mail.comcast.net) (76.96.62.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Jul 2012 01:44:50 +0000 Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id ZDgm1j0070QuhwU51Dks4J; Thu, 12 Jul 2012 01:44:52 +0000 Received: from bag6-1-pt.tunnel.tserv3.fmt2.ipv6.he.net ([IPv6:2001:470:1f04:ae1::2]) by omta02.westchester.pa.mail.comcast.net with comcast id ZDkh1j00H0P3DwE3NDkjpv; Thu, 12 Jul 2012 01:44:44 +0000 Subject: Re: PR 51094 - fprint_w() in output_addr_const() reinstated Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mike Stump In-Reply-To: Date: Thu, 12 Jul 2012 01:45:00 -0000 Cc: gcc-patches@gcc.gnu.org, Andrey Belevantsev , jason@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dimitrios Apostolou X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-07/txt/msg00425.txt.bz2 On Jul 9, 2012, at 12:54 PM, Dimitrios Apostolou wrote: > Since output_addr_const() shows pretty hot in the compiler, I reinstated = the fprint_w() call in place of fprintf(). My review bits... First there is no guarantee that HOST_WIDE_INT_BITSIZE i= s 64 or less, so [20] is unsafe longer term. You can add an assert that it= is 64 or less, that way it will be fixed when people bump things up. long= !=3D HOST_WIDE_INT, so, that's a type violation, an assert for it would ma= ke it safer. For performance, can't help but wonder if it would be faster = to process the numbers in blocks of 9 digits, so that the wide divisions ar= e fewer are farther between and for each one, you could then have 9 32-bit = divisions which should be a bit cheaper; but, that's an issue for sprint_ul= _rev, not your code.