Re: [PATCH]: initialize dconsts lazily, improve GCC startup time

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

From: "Manuel López-Ibáñez" <lopezibanez@gmail.com>

> I don't want to sound bikesheding, so feel free to ignore my comments
> if you can't bother to change your patch. Why use a switch + enum
> type? This seems too complex and without any speed benefit. Wouldn't
> it be better to use inline or macro for each constant?

No for several reasons.  First of all, most of these uses are in corner 
cases, so inlining for speed isn't worthwhile here.  Second because we're 
not going to get a speedup in most code, the approach of inlining would 
result in code bloat without benefit.  Third, each inline instance would 
have a separate static cache variable so no sharing would occur.  If you end 
up using more than one occurance, it would actually be *slower* since you're 
recalculating e.g. sqrt2 in each separate inline.

> That is in real.h for example for dconstsqrt2:
>
> #define dconst_sqrt2 get_real_dconst_sqrt2()
>
> static inline const REAL_VALUE_TYPE *
> get_real_dconst_sqrt2 (void)
> {
>  static REAL_VALUE_TYPE value = rvc_zero;
>
>  if (value == rvc_zero)
>  {
>      mpfr_t m;
>      mpfr_init2 (m, SIGNIFICAND_BITS);
>      mpfr_sqrt_ui (m, 2, GMP_RNDN);
>      real_from_mpfr (&value, m, NULL_TREE, GMP_RNDN);
>      mpfr_clear (m);
>  }
>  return &value;
> }
>
> Moreover, I think we can use __builtin_expect for the condition and
> mark the function as pure.

We can't use __builtin_expect unless support is created for non-gcc 
compilers.  I don't recall if we have magic macros to handle that yet or 
not.

WRT marking pure, the function isn't actually pure since it can abort.

> Also, dconst_x is more readable and seems more robust and consistent
> than a mix of dconstx and get_real_const (rv_x).

That seems very subjective IMHO.  There are many more instances of 
dconst*outside the scope of my patch.  If you feel strongly that it's more 
readable, feel free to submit this separately.

       Thanks,
       --Kaveh
--
Kaveh R. Ghazi