www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1475] New: allow to use intrinsic math functions (e.g. trigonometry) in CTFEs

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1475

           Summary: allow to use intrinsic math functions (e.g.
                    trigonometry) in CTFEs
           Product: D
           Version: 1.021
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: thecybershadow gmail.com


The compiler already supports some math functions, like the trigonometric ones,
as intrinsics, since it inlines them even when -inline is not specified. It
would greatly add to CTFEs if it were possible to call such functions in
compile-time functions. For example, Pi could be calculated at compile-time
using:

const double PI = atan(1)*4;

Sine tables could also be pre-calculated at compile time, etcetera.


--
Sep 05 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1475





------- Comment #1 from thecybershadow gmail.com  2007-09-05 15:06 -------
*** Bug 1476 has been marked as a duplicate of this bug. ***


--
Sep 05 2007
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1475





------- Comment #2 from wbaxter gmail.com  2007-09-05 16:10 -------
Of course you can already do this by writing your own CTFE functions to
approximate those via Taylor series and the like.  One of the first CTFE demos
was a compile-time sqrt function.

But yeh, the compiler has access to a better way to evaluate those functions
than running what amounts to an interpreted language, so it would be nice to be
able to access it.  I can imagine some sort of plugin system where you'd write
some D-code, compile it to a dll, and expose new compile-time functions to the
compiler via that dll (much as you write extensions for other scripting
languages).  And of course those initial CTFE compiler extensions could be used
to compile further CTFE compiler extensions... and so on.


--
Sep 05 2007
next sibling parent reply BCS <BCS pathlink.com> writes:
d-bugmail puremagic.com wrote:

 http://d.puremagic.com/issues/show_bug.cgi?id=1475
 
 
 
 
 
 ------- Comment #2 from wbaxter gmail.com  2007-09-05 16:10 -------
 Of course you can already do this by writing your own CTFE functions to
 approximate those via Taylor series and the like.  One of the first CTFE demos
 was a compile-time sqrt function.
 
 But yeh, the compiler has access to a better way to evaluate those functions
 than running what amounts to an interpreted language, so it would be nice to be
 able to access it.  I can imagine some sort of plugin system where you'd write
 some D-code, compile it to a dll, and expose new compile-time functions to the
 compiler via that dll (much as you write extensions for other scripting
 languages).  And of course those initial CTFE compiler extensions could be used
 to compile further CTFE compiler extensions... and so on.
 
 


As long as you aren't cross compiling, The compiler could take the 
version of the function it's going to put in the obj, plop it down in 
memory and run it. Why use DLLs?
Sep 05 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:

 d-bugmail puremagic.com wrote:

 http://d.puremagic.com/issues/show_bug.cgi?id=1475





 ------- Comment #2 from wbaxter gmail.com  2007-09-05 16:10 -------
 Of course you can already do this by writing your own CTFE functions to
 approximate those via Taylor series and the like.  One of the first 
 CTFE demos
 was a compile-time sqrt function.

 But yeh, the compiler has access to a better way to evaluate those 
 functions
 than running what amounts to an interpreted language, so it would be 
 nice to be
 able to access it.  I can imagine some sort of plugin system where 
 you'd write
 some D-code, compile it to a dll, and expose new compile-time 
 functions to the
 compiler via that dll (much as you write extensions for other scripting
 languages).  And of course those initial CTFE compiler extensions 
 could be used
 to compile further CTFE compiler extensions... and so on.


 
 As long as you aren't cross compiling, The compiler could take the 
 version of the function it's going to put in the obj, plop it down in 
 memory and run it. Why use DLLs?


Sure, implementation detail.  :-)
There might be some value in having such CTFE libraries be 
redistributable though?  Probably gets in to security risk territory, 
though.

--bb
Sep 05 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
d-bugmail puremagic.com wrote:

 ------- Comment #2 from wbaxter gmail.com  2007-09-05 16:10 -------
 Of course you can already do this by writing your own CTFE functions to
 approximate those via Taylor series and the like.  One of the first CTFE demos
 was a compile-time sqrt function.
 
 But yeh, the compiler has access to a better way to evaluate those functions
 than running what amounts to an interpreted language, so it would be nice to be
 able to access it.


It was my impression that CTFE relies on a fancy version of constant 
folding, which doesn't make support for any special routines or plugins 
a really natural fit.  And while it seems like a potentially interesting 
feature to add, I wonder whether there might be issues related to cross 
compilation.
Sep 05 2007
parent reply BCS <BCS pathlink.com> writes:
Sean Kelly wrote:

 d-bugmail puremagic.com wrote:
 

 ------- Comment #2 from wbaxter gmail.com  2007-09-05 16:10 -------
 Of course you can already do this by writing your own CTFE functions to
 approximate those via Taylor series and the like.  One of the first 
 CTFE demos
 was a compile-time sqrt function.

 But yeh, the compiler has access to a better way to evaluate those 
 functions
 than running what amounts to an interpreted language, so it would be 
 nice to be
 able to access it.


 
 
 It was my impression that CTFE relies on a fancy version of constant 
 folding, which doesn't make support for any special routines or plugins 
 a really natural fit.  And while it seems like a potentially interesting 
 feature to add, I wonder whether there might be issues related to cross 
 compilation.


Intrinsics are just function that get special handling. Something akin 
to that could be done for CTFE. Put some special case rules in the 
engine for sin/cos/tan/etc. that call functions that are part of the 
compiler.
Sep 05 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:

 Sean Kelly wrote:

 d-bugmail puremagic.com wrote:


 ------- Comment #2 from wbaxter gmail.com  2007-09-05 16:10 -------
 Of course you can already do this by writing your own CTFE functions to
 approximate those via Taylor series and the like.  One of the first 
 CTFE demos
 was a compile-time sqrt function.

 But yeh, the compiler has access to a better way to evaluate those 
 functions
 than running what amounts to an interpreted language, so it would be 
 nice to be
 able to access it.



 It was my impression that CTFE relies on a fancy version of constant 
 folding, which doesn't make support for any special routines or 
 plugins a really natural fit.  




Check out dmd/src/dmd/constfold.c and interpret.c.   It's basically a 
little compile time code interpreter.  So yes, it's "fancy constant 
folding" but "fancy" in this case means "it runs a small interpreted 
subset of D". For instance there's a function Cat there which apparently 
does array concatenation.  There's a Div() that does division.  There's 
no reason there couldn't be a function called "Cos" in there that 
computed the cosine of its argument at compile time.  But why stop at Cos?

Wouldn't it be nice if users could add other functions like Cos that 
could be called at compile time?  If they could extend the 
constant-folding interpreter with new built-in functions written in D or 
asm or whatever is convenient.  Mr. thecybershadow needs sin and cos, 
but maybe I need erf(), or maybe I'd like to call BLAS to precompute the 
LU decomposition of some matrix to use as a constant.  Or maybe I'd like 
to have a constant initialized with a string representing the current 
date and time.

So then the question becomes how do you enable constfold.c to call code 
that it doesn't know about it?  That's why I went for DLLs first. 
That's how other interpreted languages are usually extended with 
functionality that can't be expressed in the the language itself, or 
functionality which is available in foreign code.  But maybe BCS is 
right that, since what we're talking about *is* a D compiler to begin 
with, maybe it could access the results of it's own output in a more 
direct way.  I think that would be tough to implement, though, since 
code generation happens miles away from where constfold.c is doing its 
thing.



 And while it seems like a potentially 
 interesting feature to add, I wonder whether there might be issues 
 related to cross compilation.




I don't think anything more than the usual "feature X not supported on 
platform Y".

I think the bigger issue is probably that Walter doesn't want the 
compiler to become a vector for running arbitrary code.  "Hey can you 
compile this D code for me" should never be a way to pz0wn a computer, 
at least according to Walter.


 Intrinsics are just function that get special handling. Something akin 
 to that could be done for CTFE. Put some special case rules in the 
 engine for sin/cos/tan/etc. that call functions that are part of the 
 compiler.


Yeh.  Looking at constfold.c, I think Walter could have probably already 
implemented this for sin/cos/tan in less than the time it took me to 
write this message.  But if sin/cos/tan go in, what about erf, what 
about gettimeofday?  where do you stop?  The classic answer to that is 
"let the user decide" by making it possible to write libraries.

--bb
Sep 05 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1475





------- Comment #4 from wbaxter gmail.com  2007-09-05 19:46 -------

 Sine tables could also be pre-calculated at compile time, etcetera.


The ironic thing is that if you wanted to implement a CTFE sine function right
now, table lookup is probably the most reasonable way to do it.


Anyway, I like the general idea, and I think the same thing goes for many other
things, like string formatting functions.  There's a perfectly fine string
formatter in std.string.format.  It's a shame the compiler isn't able to invoke
it during compile time.


--
Sep 05 2007
prev sibling next sibling parent Ingo Oeser <ioe-news rameria.de> writes:
d-bugmail puremagic.com wrote:


 The compiler already supports some math functions, like the trigonometric
 ones, as intrinsics, since it inlines them even when -inline is not
 specified. It would greatly add to CTFEs if it were possible to call such
 functions in compile-time functions. For example, Pi could be calculated
 at compile-time using:
 
 const double PI = atan(1)*4;
 
 Sine tables could also be pre-calculated at compile time, etcetera.


Quoting http://gcc.gnu.org/gcc-4.3/changes.html
"The GCC middle-end has been integrated with the MPFR library. This allows
GCC to evaluate and replace at compile-time calls to built-in math
functions having constant arguments with their mathematically equivalent
results. In making use of MPFR, GCC can generate correct results regardless
of the math library implementation or floating point precision of the host
platform. This also allows GCC to generate identical results regardless of
whether one compiles in native or cross-compile configurations to a
particular target. The following built-in functions take advantage of this
new capability: acos, acosh, asin, asinh, atan2, atan, atanh, cbrt, cos,
cosh, drem, erf, erfc, exp10, exp2, exp, expm1, fdim, fma, fmax, fmin,
gamma_r, hypot, j0, j1, jn, lgamma_r, log10, log1p, log2, log, pow10, pow,
remainder, remquo, sin, sincos, sinh, tan, tanh, tgamma, y0, y1 and yn. The
float and long double variants of these functions (e.g. sinf and sinl) are
also handled. The sqrt and cabs functions with constant arguments were
already optimized in prior GCC releases. Now they also use MPFR."

So GDC might be able to do this, if ported to GCC 4.3 backend and it
patches some frontend parts :-)

Maybe there is a similar solution with a different license to be
able to use that in DMD.


Best Regards

Ingo Oeser
Sep 06 2007
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1475


clugdbug yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #5 from clugdbug yahoo.com.au  2009-04-06 03:11 -------
The intrinsics were included in constant folding in DMD2.005.
It'd be good to have a way of detecting CTFE inside a function, so that the
other math functions could be made CTFE-able (many of them use asm) -- but
that's a different issue.


--
Apr 06 2009