Compile-time optimization of mathfn(CST) ?

Compile-time optimization of mathfn(CST) ?

[Kaveh R. Ghazi]

I'm wondering whether we can safely optimize builtin mathfn(CST) into
a compile-time value by calling the host's `mathfn' when not
cross-compiling.

I understand that in the past it's been discussed that we need to use
GMP's library to calculate the constant results to sufficient digits
in the case where the target's FP has greater precision.  However I
don't see anyone working on this yet, (including me.)

So I'm wondering if we can simply call the host math functions and
wrap this in !CROSS_COMPILE so that we catch a vast portion of the
cases where this transformation is useful.

Thoughts?

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Compile-time optimization of mathfn(CST) ?

[Joseph S. Myers]

On Thu, 25 Mar 2004, Kaveh R. Ghazi wrote:

> I understand that in the past it's been discussed that we need to use
> GMP's library to calculate the constant results to sufficient digits
> in the case where the target's FP has greater precision.  However I
> don't see anyone working on this yet, (including me.)

Once tree-ssa is merged to mainline there's likely to be more interest in
importing GMP (as a necessary prerequisite to this).

> So I'm wondering if we can simply call the host math functions and
> wrap this in !CROSS_COMPILE so that we catch a vast portion of the
> cases where this transformation is useful.

Generated code for a given target depending on whether cross-compiling, or
on the fine details of the host libc version or precise CPU stepping seems
a bad idea.  (The dependence on the CPU version, where the host library
uses CPU instructions for the operation but not all CPUs necessarily
produce bitwise identical results, would in particular be liable to
produce nonreproducibility for distcc compiles etc. - I don't think people
using compile farms necessarily use physically identical processors on all
machines.)

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: Compile-time optimization of mathfn(CST) ?

[Kaveh R. Ghazi]

 > From: "Joseph S. Myers" <jsm@polyomino.org.uk>
 > 
 > [...] or precise CPU stepping seems a bad idea.  (The dependence on
 > the CPU version, where the host library uses CPU instructions for
 > the operation but not all CPUs necessarily produce bitwise
 > identical results, would in particular be liable to produce
 > nonreproducibility for distcc compiles etc. - I don't think people
 > using compile farms necessarily use physically identical processors
 > on all machines.)

Ok I buy this one, GCC should be deterministic on compile farms.

So I await GMP.  Sigh.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Compile-time optimization of mathfn(CST) ?

[Bernd Jendrissek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Mar 25, 2004 at 08:20:52AM -0500, Kaveh R. Ghazi wrote:
> I'm wondering whether we can safely optimize builtin mathfn(CST) into
> a compile-time value by calling the host's `mathfn' when not
> cross-compiling.
> 
> I understand that in the past it's been discussed that we need to use
> GMP's library to calculate the constant results to sufficient digits
> in the case where the target's FP has greater precision.  However I
> don't see anyone working on this yet, (including me.)
> 
> So I'm wondering if we can simply call the host math functions and
> wrap this in !CROSS_COMPILE so that we catch a vast portion of the
> cases where this transformation is useful.

So you'll produce different object code depending on whether a native or
a cross compiler produced the code?  How will the regression testers
like that?

Or maybe you can add __builtin_native_evaluate() that you can put around
__builtin_sin() that will tell GCC that you want the result evaluated
NOW (IOW compile-time).  Then you have control over native-vs-cross
inconsistencies where it belongs - in the source.

- -- 
"IBM has more patent litigation lawyers than SCO has employees." - unknown
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAY9Wg/FmLrNfLpjMRAlxbAJ0TNGLd46+aZh9Jlc8K5xj/lYJ7igCfRQGk
LmWf3BrwVpuYTEqaUYmofe4=
=YC9D
-----END PGP SIGNATURE-----