CTFE pow()

[Xinok via Digitalmars-d]

On Thursday, 1 January 2015 at 18:43:12 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Fri, Jan 02, 2015 at 02:56:16AM +1000, Manu via 
> Digitalmars-d wrote:
>> Does anyone know how to fix this? Can we please do so? It's 
>> been a
>> problem for like 5 years it seems.
>> It's a bit insane that we can't resolve any non-linear 
>> functions at
>> compile time.
>
> I've been waiting for this since like, forever. We even have a 
> D code
> implementation of pow() already (thanks to Iain), which 
> *should* have
> been CTFE-able, if it weren't for CTFE limitations that prohibit
> reinterpreting float values in binary, which is required for 
> certain
> basic operations like isInfinite, isNaN, etc..
>
> So it seems that the blocker right now is CTFE, which, 
> unfortunately, is
> not a pretty piece of code, and requires quite a bit of care to 
> get it
> done right.
>
>
> T

I'm wondering if there's any added benefit to implementing these 
as intrinsic functions instead? In this way, implementing them in 
CTFE should be trivial and the extra knowledge given to the 
compiler could enable extra optimizations that wouldn't be 
possible otherwise. For example, the compiler understands 
multiplication and division so, in certain cases, it can replace 
these operations with bit-shifting which is faster.