This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: initialize dconsts lazily, improve GCC startup time
From: "Manuel López-Ibáñez" <firstname.lastname@example.org>
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 *
static REAL_VALUE_TYPE value = rvc_zero;
if (value == rvc_zero)
mpfr_init2 (m, SIGNIFICAND_BITS);
mpfr_sqrt_ui (m, 2, GMP_RNDN);
real_from_mpfr (&value, m, NULL_TREE, GMP_RNDN);
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
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.
Kaveh R. Ghazi