https://d.puremagic.com/issues/show_bug.cgi?id=3749


Iain Buclaw <ibuclaw@ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@ubuntu.com


--- Comment #11 from Iain Buclaw <ibuclaw@ubuntu.com> 2014-01-07 14:56:54 PST ---
(In reply to comment #10)
> What's the state of this?
> Having log/exp functions at compile time would be very useful, e.g. to
> pregenerate scientific tables.

std.math now has pure generic implementations.

One of the main problems holding CTFE support back is that there is no straightforward way to do math operations such as isNaN, isInfinity, signbit, frexp which require access (and for some, manipulation) of the bits in float types.

GDC has the ability to convert float <-> array already in place, but its not in use because CTFE doesn't allow it.

Saying that, DMD has a problem that GDC doesn't - it uses the IASM implementations of std.math functions that can't be evaluated at compile time.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=3749



--- Comment #12 from Martin Nowak <code@dawg.eu> 2014-01-07 19:47:17 PST ---
(In reply to comment #11)
> (In reply to comment #10)
> > What's the state of this?
> > Having log/exp functions at compile time would be very useful, e.g. to
> > pregenerate scientific tables.
> 
> std.math now has pure generic implementations.
> 
> One of the main problems holding CTFE support back is that there is no straightforward way to do math operations such as isNaN, isInfinity, signbit, frexp which require access (and for some, manipulation) of the bits in float types.

We had the same issue with hashOf in druntime and now there is a huge machinery
to compute exponent and mantissa.
Could we allow to read specific floating point values through intrinsics at
compile time?
Something like exponent(float), signbit(float), mantissa(float)?

> Saying that, DMD has a problem that GDC doesn't - it uses the IASM implementations of std.math functions that can't be evaluated at compile time.

How do you treat std.math.log at runtime as intrinsic or does it run the same code? Is there a performance penalty?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=3749



--- Comment #13 from Iain Buclaw <ibuclaw@ubuntu.com> 2014-01-08 04:31:41 PST ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > What's the state of this?
> > > Having log/exp functions at compile time would be very useful, e.g. to
> > > pregenerate scientific tables.
> > 
> > std.math now has pure generic implementations.
> > 
> > One of the main problems holding CTFE support back is that there is no straightforward way to do math operations such as isNaN, isInfinity, signbit, frexp which require access (and for some, manipulation) of the bits in float types.
> 
> We had the same issue with hashOf in druntime and now there is a huge machinery
> to compute exponent and mantissa.
> Could we allow to read specific floating point values through intrinsics at
> compile time?
> Something like exponent(float), signbit(float), mantissa(float)?
> 



> > Saying that, DMD has a problem that GDC doesn't - it uses the IASM implementations of std.math functions that can't be evaluated at compile time.
> 
> How do you treat std.math.log at runtime as intrinsic or does it run the same code? Is there a performance penalty?

We don't implement y2lx in GDC, so it uses the !INLINE_Y2LX implemenatation. :)

If you instead meant eg: std.math.sin, this is the process (approximately).

User code (import std.math)
-> Compiler registers real sin() as BUILT_IN_FRONTEND

User code calls std.math.sin
-> CTFE sees function is BUILTINsin and calls eval_builtin()
-> eval_builtin generates call to BUILT_IN_SINL and then calls fold_builtin()
-> fold_builtin validates input parameters and calls mpfr_sin()
-> Returns MPFR evaluated value to fold_builtin as GCC tree.
-> Returns GCC tree to eval_builtin which converts it to RealExp value.

Compiler unable to fold builtin
-> Returns CallExp to C math lib function sin()

It's a long winded way, and I'd like to ideally skip passing through the middle-end and call MPFR directly. :)

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=3749



--- Comment #14 from Iain Buclaw <ibuclaw@ubuntu.com> 2014-01-08 04:37:37 PST ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > (In reply to comment #10)
> > > > What's the state of this?
> > > > Having log/exp functions at compile time would be very useful, e.g. to
> > > > pregenerate scientific tables.
> > > 
> > > std.math now has pure generic implementations.
> > > 
> > > One of the main problems holding CTFE support back is that there is no straightforward way to do math operations such as isNaN, isInfinity, signbit, frexp which require access (and for some, manipulation) of the bits in float types.
> > 
> > We had the same issue with hashOf in druntime and now there is a huge machinery to compute exponent and mantissa.

I don't honestly know what to say about that.  I've not tested it and I'm anticipating it to simply not work in GDC.

> > Could we allow to read specific floating point values through intrinsics at
> > compile time?
> > Something like exponent(float), signbit(float), mantissa(float)?
> > 
> 

Something like this was suggested and discarded IIRC.  I'm not sure how I would be able to do this from within GCC's infrastructure - or at least return meaningful / usable data in the case of exponent and mantissa bits. :)

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=3749



--- Comment #15 from Martin Nowak <code@dawg.eu> 2014-01-08 17:07:23 PST ---
(In reply to comment #13)

> We don't implement y2lx in GDC, so it uses the !INLINE_Y2LX implemenatation. :)

At runtime? I'm quite surprised to hear that, isn't the performance a bummer compared to the X87 instruction? On other platforms this might not an argument though.

(In reply to comment #14)
> > > Something like exponent(float), signbit(float), mantissa(float)?
> 
> Something like this was suggested and discarded IIRC.  I'm not sure how I would be able to do this from within GCC's infrastructure - or at least return meaningful / usable data in the case of exponent and mantissa bits. :)

Well the parse(Float)(Float f) function only uses normal CTFE floating point
computations to determine these values.
https://github.com/D-Programming-Language/druntime/blob/a977a65ac7df366c002033c43e11cd05925a25fb/src/core/internal/convert.d#L91
It's quite complex, so you can see how desperate we are to get CT hashing.
Although we might disable CT hashing for floats if this gets out of hand.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=3749



--- Comment #16 from Iain Buclaw <ibuclaw@ubuntu.com> 2014-01-09 03:04:44 PST ---
(In reply to comment #15)
> (In reply to comment #13)
> 
> > We don't implement y2lx in GDC, so it uses the !INLINE_Y2LX implemenatation. :)
> 
> At runtime? I'm quite surprised to hear that, isn't the performance a bummer compared to the X87 instruction? On other platforms this might not an argument though.
> 

I guess so. But I don't give x86 any favours over other targets in the glue. (I kicked out all x86-specific codegen last year :)

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------