PR 51094 - fprint_w() in output_addr_const() reinstated

Since output_addr_const() shows pretty hot in the compiler, I reinstated 
the fprint_w() call in place of fprintf().

This patch relies on two things: 2's complement representation for 
negative int and that HOST_WIDE_INT is at least as large type as long for 
all platforms (will it always be?).

Bootstrapped/tested on i386, regtested on x86_64 multilib, 
i386-pc-solaris2.10 (thanks ro), i686-darwin9 (thanks iains).


2012-07-09 Dimitrios Apostolou <jimis@gmx.net>

         * final.c, output.h (fprint_w): New function to write a
         HOST_WIDE_INT to a file, fast.
         * final.c (output_addr_const): Use fprint_w() instead of
         fprintf().
         (sprint_ul_rev): New static function to write a
         HOST_WIDE_INT to a string in reverse, fast.



Thanks,
Dimitris

On Mon, 9 Jul 2012, Dimitrios Apostolou wrote:
> Since output_addr_const() shows pretty hot in the compiler, I reinstated the
> fprint_w() call in place of fprintf().
>
> This patch relies on two things: 2's complement representation for negative
> int and that HOST_WIDE_INT is at least as large type as long for all platforms
> (will it always be?).
>
> Bootstrapped/tested on i386, regtested on x86_64 multilib, i386-pc-solaris2.10
> (thanks ro), i686-darwin9 (thanks iains).
>
>
> 2012-07-09 Dimitrios Apostolou <jimis@gmx.net>
>
>         * final.c, output.h (fprint_w): New function to write a
>         HOST_WIDE_INT to a file, fast.
>         * final.c (output_addr_const): Use fprint_w() instead of
>         fprintf().
>         (sprint_ul_rev): New static function to write a
>         HOST_WIDE_INT to a string in reverse, fast.

(Non-inlined patch, so I can't quote the patch in pine.)

Non-approver review: looks ok besides a few cases of comment
formatting nits: punctuation at end and two spaces: ".  */"
You had it right in the first sentence.  (The original wasn't
right either.)

Maybe also add a comment about how much faster than fprintf this
is, besides the ", fast".

brgds, H-P

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 is 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 != HOST_WIDE_INT, so, that's a type violation, an assert for it would make 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 are 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.

Dimitrios Apostolou <jimis@gmx.net> writes:

> @@ -3849,6 +3850,32 @@ sprint_ul_rev (char *s, unsigned long va
>    return i;
>  }
>  
> +/* Write a signed HOST_WIDE_INT as decimal to a file, fast. */
> +
> +void
> +fprint_w (FILE *f, HOST_WIDE_INT value)
> +{
> +  /* python says: len(str(2**64)) == 20 */
> +  char s[20];

From gnulib:

/* Bound on length of the string representing an unsigned integer
   value representable in B bits.  log10 (2.0) < 146/485.  The
   smallest value of B where this bound is not tight is 2621.  */
#define INT_BITS_STRLEN_BOUND(b) (((b) * 146 + 484) / 485)

Andreas.