www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - !!!Please add intrinsics module for DMD DRuntime!!!

reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
Hey all,

Please add a module (core.intrinsics ?) which will contain all 
DMD intrinsics similar to ldc.intrinsics. After each DMD release 
it is not clear what is intrinsics and what is not. I need BSF 
intrinsics for Better C library Mir Random [1], which should work 
without linking with DRuntime and Phobos. I can use 
ldc.intrinsics for LDC, but have no idea about DMD. I want BSR 
and BSF instructions to be generated instead of current 
_software_ implementation in core.bitop.

==================
Philosophical Questions:

1. Why hight level stuff like BitRange is in core.bitop, but not 
in std.bitmanip? If it should be in core, why it is public?

2. Why bsf and bsr do NOT use hardware instructions anymore?
==================

Please ping me for Phobos and DRuntime PRs if they are related to 
math and numeric issues.

Best regards,
Ilya
Nov 22 2016
next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
[1] https://github.com/libmir/mir-random
Nov 22 2016
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/22/16 8:31 AM, Ilya Yaroshenko wrote:
 Philosophical Questions:

 1. Why hight level stuff like BitRange is in core.bitop, but not in
 std.bitmanip? If it should be in core, why it is public?
I wrote BitRange to help with cycle detection. It was related to using the btc/btr/bt functions on bit arrays (it's meant to wrap such a bit array), so that seemed like a natural place for it. Putting it in std.bitmanip would make it unavailable to druntime. Why shouldn't it be public?
 2. Why bsf and bsr do NOT use hardware instructions anymore?
They should unless there is no hardware instruction available. I believe the software implementation is only a fallback when this is the case. -Steve
Nov 22 2016
next sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Tuesday, 22 November 2016 at 16:07:39 UTC, Steven 
Schveighoffer wrote:
 On 11/22/16 8:31 AM, Ilya Yaroshenko wrote:
 Philosophical Questions:

 1. Why hight level stuff like BitRange is in core.bitop, but 
 not in
 std.bitmanip? If it should be in core, why it is public?
I wrote BitRange to help with cycle detection. It was related to using the btc/btr/bt functions on bit arrays (it's meant to wrap such a bit array), so that seemed like a natural place for it. Putting it in std.bitmanip would make it unavailable to druntime. Why shouldn't it be public?
 2. Why bsf and bsr do NOT use hardware instructions anymore?
They should unless there is no hardware instruction available. I believe the software implementation is only a fallback when this is the case. -Steve
They are always software https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya
Nov 22 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:
 They are always software
 https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya
The intent is to have the compiler detect the pattern and insert the code. dmd does that IIRC (why is asm.dlang.org not working again?) and so does gdc: https://godbolt.org/g/WspkIX. -- Andrei
Nov 22 2016
next sibling parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 22 November 2016 at 16:36:13 UTC, Andrei Alexandrescu 
wrote:
 On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:
 They are always software
 https://github.com/dlang/druntime/blob/master/src/core/bitop.d 
 --Ilya
The intent is to have the compiler detect the pattern and insert the code. dmd does that IIRC (why is asm.dlang.org not working again?) and so does gdc: https://godbolt.org/g/WspkIX.
LDC too. https://godbolt.org/g/S83b30 (note that cross-module inlining is off by default, something to work on for 1.2.0!)
Nov 22 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Tuesday, 22 November 2016 at 16:52:40 UTC, Johan Engelen wrote:
 On Tuesday, 22 November 2016 at 16:36:13 UTC, Andrei 
 Alexandrescu wrote:
 On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:
 They are always software
 https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya
The intent is to have the compiler detect the pattern and insert the code. dmd does that IIRC (why is asm.dlang.org not working again?) and so does gdc: https://godbolt.org/g/WspkIX.
LDC too. https://godbolt.org/g/S83b30 (note that cross-module inlining is off by default, something to work on for 1.2.0!)
No, LDC and GDC cannot detect it. Proof - https://godbolt.org/g/bsAFU8 . Current LDC DRuntime uses intrinsics instead of software implementation. Ilya
Nov 22 2016
next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 22 November 2016 at 17:07:08 UTC, Ilya Yaroshenko 
wrote:
 No, LDC and GDC cannot detect it. Proof - 
 https://godbolt.org/g/bsAFU8 . Current LDC DRuntime uses 
 intrinsics instead of software implementation.

 Ilya
Your test fails because you aren't actually using `core.bitop`. Intrinsics are detected based on fully qualified names. As soon as you copy `bsf()` and `bsr()` outside of `core.bitop`, the FQN changes and they're not intrinsics anymore.
Nov 22 2016
next sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Tuesday, 22 November 2016 at 18:57:59 UTC, tsbockman wrote:
 On Tuesday, 22 November 2016 at 17:07:08 UTC, Ilya Yaroshenko 
 wrote:
 No, LDC and GDC cannot detect it. Proof - 
 https://godbolt.org/g/bsAFU8 . Current LDC DRuntime uses 
 intrinsics instead of software implementation.

 Ilya
Your test fails because you aren't actually using `core.bitop`. Intrinsics are detected based on fully qualified names. As soon as you copy `bsf()` and `bsr()` outside of `core.bitop`, the FQN changes and they're not intrinsics anymore.
Does DMD overrides bodies for bsf and bsr? It would be surprised to me.
Nov 22 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 22 November 2016 at 19:27:11 UTC, Ilya Yaroshenko 
wrote:
 On Tuesday, 22 November 2016 at 18:57:59 UTC, tsbockman wrote:
 Your test fails because you aren't actually using 
 `core.bitop`. Intrinsics are detected based on fully qualified 
 names. As soon as you copy `bsf()` and `bsr()` outside of 
 `core.bitop`, the FQN changes and they're not intrinsics 
 anymore.
Does DMD overrides bodies for bsf and bsr? It would be surprised to me.
That's how (almost) ALL of the intrinsics in `core.bitop` and `core.math` are supposed to work. If it's not overriding the bodies, that's a bug.
Nov 22 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Tuesday, 22 November 2016 at 19:29:30 UTC, tsbockman wrote:
 On Tuesday, 22 November 2016 at 19:27:11 UTC, Ilya Yaroshenko 
 wrote:
 On Tuesday, 22 November 2016 at 18:57:59 UTC, tsbockman wrote:
 Your test fails because you aren't actually using 
 `core.bitop`. Intrinsics are detected based on fully 
 qualified names. As soon as you copy `bsf()` and `bsr()` 
 outside of `core.bitop`, the FQN changes and they're not 
 intrinsics anymore.
Does DMD overrides bodies for bsf and bsr? It would be surprised to me.
That's how (almost) ALL of the intrinsics in `core.bitop` and `core.math` are supposed to work. If it's not overriding the bodies, that's a bug.
DMD can recognise code patterns and replace them with hardware functions. I never seen that it can replace bodies. Why do you think it can? Have you disassembler DMD the code with your PR?
Nov 22 2016
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tuesday, 22 November 2016 at 19:43:14 UTC, Ilya Yaroshenko 
wrote:
 Why do you think it can?
'cause it is in compiler sources.
Nov 22 2016
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-11-22 20:43, Ilya Yaroshenko wrote:

 DMD can recognise code patterns and replace them with hardware
 functions. I never seen that it can replace bodies. Why do you think it
 can? Have you disassembler DMD the code with your PR?
Here are all the built-in functions [1]. It's looking at the mangled name. [1] https://github.com/dlang/dmd/blob/master/src/builtin.d#L186 -- /Jacob Carlborg
Nov 23 2016
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/22/16 1:57 PM, tsbockman wrote:
 Your test fails because you aren't actually using `core.bitop`.
 Intrinsics are detected based on fully qualified names. As soon as you
 copy `bsf()` and `bsr()` outside of `core.bitop`, the FQN changes and
 they're not intrinsics anymore.
Thanks, didn't know how it works. We should document that clearly so as to avoid confusions in the future. -- Andrei
Nov 22 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/22/2016 10:57 AM, tsbockman wrote:
 Your test fails because you aren't actually using `core.bitop`. Intrinsics are
 detected based on fully qualified names. As soon as you copy `bsf()` and
`bsr()`
 outside of `core.bitop`, the FQN changes and they're not intrinsics anymore.
That is correct. From toir.d, this is what is detected: "_D4core5bitop3bsfFNaNbNiNfkZi" i.e. the fully mangled name. Detecting any function called "bsf" would be problematic because it would essentially add an arbitrary number of reserved words to the core language. An alternative would be to name them with a prefix like: __intrinsic_bsf but I see little advantage to that over core.bitop.bsf
Nov 22 2016
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 22 November 2016 at 18:07, Ilya Yaroshenko via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 22 November 2016 at 16:52:40 UTC, Johan Engelen wrote:
 On Tuesday, 22 November 2016 at 16:36:13 UTC, Andrei Alexandrescu wrote:
 On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:
 They are always software
 https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya
The intent is to have the compiler detect the pattern and insert the code. dmd does that IIRC (why is asm.dlang.org not working again?) and so does gdc: https://godbolt.org/g/WspkIX.
LDC too. https://godbolt.org/g/S83b30 (note that cross-module inlining is off by default, something to work on for 1.2.0!)
No, LDC and GDC cannot detect it. Proof - https://godbolt.org/g/bsAFU8 . Current LDC DRuntime uses intrinsics instead of software implementation. Ilya
Fixed that for you. Unfortunately it seems LDC just isn't clever enough. https://godbolt.org/g/quBpEq Iain
Nov 22 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/22/2016 9:07 AM, Ilya Yaroshenko wrote:
 No, LDC and GDC cannot detect it. Proof - https://godbolt.org/g/bsAFU8 .
Current
 LDC DRuntime uses intrinsics instead of software implementation.
Consider the code: import core.bitop; int foo(int v) { return core.bitop.bsf(v); } Compiling: dmd foo.d -c obj2asm foo.obj yields: _D5bug113fooFiZi comdat bsf EAX,AL ret Meaning the bsf() intrinsic is properly detected and used.
Nov 22 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Wednesday, 23 November 2016 at 00:52:15 UTC, Walter Bright 
wrote:
 Consider the code:

   import core.bitop;

   int foo(int v) {
     return core.bitop.bsf(v);
   }

 Compiling:

   dmd foo.d -c
   obj2asm foo.obj

 yields:

   _D5bug113fooFiZi        comdat
                 bsf     EAX,AL
                 ret

 Meaning the bsf() intrinsic is properly detected and used.
I did some additional testing, and it seems that the bsf and bsr intrinsics are only working *sometimes* on DMD master: https://issues.dlang.org/show_bug.cgi?id=16743
Nov 23 2016
next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Wednesday, 23 November 2016 at 19:57:15 UTC, tsbockman wrote:
 On Wednesday, 23 November 2016 at 00:52:15 UTC, Walter Bright 
 wrote:
 Consider the code:

   import core.bitop;

   int foo(int v) {
     return core.bitop.bsf(v);
   }

 Compiling:

   dmd foo.d -c
   obj2asm foo.obj

 yields:

   _D5bug113fooFiZi        comdat
                 bsf     EAX,AL
                 ret

 Meaning the bsf() intrinsic is properly detected and used.
I did some additional testing, and it seems that the bsf and bsr intrinsics are only working *sometimes* on DMD master: https://issues.dlang.org/show_bug.cgi?id=16743
Thank you for filling the bug
Nov 23 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/23/2016 11:57 AM, tsbockman wrote:
 I did some additional testing, and it seems that the bsf and bsr intrinsics are
 only working *sometimes* on DMD master:
     https://issues.dlang.org/show_bug.cgi?id=16743
Yeah, you're right. Will fix.
Nov 23 2016
prev sibling next sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Tuesday, 22 November 2016 at 16:36:13 UTC, Andrei Alexandrescu 
wrote:
 On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:
 They are always software
 https://github.com/dlang/druntime/blob/master/src/core/bitop.d 
 --Ilya
The intent is to have the compiler detect the pattern and insert the code. dmd does that IIRC (why is asm.dlang.org not working again?) and so does gdc: https://godbolt.org/g/WspkIX. -- Andrei
GDC and LDC can not detect it, I don't think DMD can. Proof - https://godbolt.org/g/bsAFU8 . Your link refers to GDC with an old DRuntime, which have bsr intrinsics instead of current software code. In addition, i need to be sure that an intrinsics function is always inlined (without -inline flag too). --Ilya
Nov 22 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/22/2016 9:05 AM, Ilya Yaroshenko wrote:
 In addition, i need to be sure that an intrinsics function is always inlined
 (without -inline flag too).
If it is a supported intrinsic, it is always inlined. There'd be no purpose to it otherwise :-)
Nov 22 2016
prev sibling next sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 22.11.2016 v 17:36 Andrei Alexandrescu via Digitalmars-d napsal(a):

 On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:
 They are always software
 https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya
The intent is to have the compiler detect the pattern and insert the code. dmd does that IIRC (why is asm.dlang.org not working again?) and so does gdc: https://godbolt.org/g/WspkIX. -- Andrei
WTF? I hope you are not serious?
Nov 22 2016
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 22 November 2016 at 23:29, Daniel Kozak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Dne 22.11.2016 v 17:36 Andrei Alexandrescu via Digitalmars-d napsal(a):


 On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:
 They are always software
 https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya
The intent is to have the compiler detect the pattern and insert the code. dmd does that IIRC (why is asm.dlang.org not working again?) and so does gdc: https://godbolt.org/g/WspkIX. -- Andrei
WTF? I hope you are not serious?
Ilya, Andrei, or both? It's a compilers job is to detect code patterns and emit suitable instructions for them. :-)
Nov 22 2016
parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 22 November 2016 at 22:57:22 UTC, Iain Buclaw wrote:
 On 22 November 2016 at 23:29, Daniel Kozak via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 Dne 22.11.2016 v 17:36 Andrei Alexandrescu via Digitalmars-d 
 napsal(a):
 The intent is to have the compiler detect the pattern and 
 insert the code. dmd does that IIRC (why is asm.dlang.org not 
 working again?) and so does gdc: 
 https://godbolt.org/g/WspkIX. -- Andrei
WTF? I hope you are not serious?
Ilya, Andrei, or both? It's a compilers job is to detect code patterns and emit suitable instructions for them. :-)
None of the compilers detect the body code pattern. I believe DMD and GDC just detect the mangled function name. Indeed, changing the function body to something else will still emit a "bsr" asm instruction: https://godbolt.org/g/x3WiEt LDC chose to reimplement the functions using intrinsics.
Nov 22 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/22/2016 3:07 PM, Johan Engelen wrote:
 On Tuesday, 22 November 2016 at 22:57:22 UTC, Iain Buclaw wrote:
 It's a compilers job is to detect code patterns and emit suitable instructions
 for them. :-)
None of the compilers detect the body code pattern.
That is correct as far as bsf/bsr are concerned. The trouble with detecting a coding pattern is there are an endless number of ways such can be coded, and the compiler cannot detect all of them. Worse, the only way you can tell if the compiler did detect it is to look at the assembler output. Nevertheless, the compiler still does detect some patterns, like for rol() and ror(), and uses a built-in operator for them. So that people use the detectable patterns, use the rol() template in core.bitop. The reason the compiler attempts to detect them anyway is there's a ton of code out there that has specific code written for rol/ror, and it's unlikely that people will ever rewrite it to use the templates. You'll find that C/C++ compilers behave similarly. Burt Regehr did a blog entry on that a while back. The compiler will also detect common forms of little/big endian byte manipulation, again see Regehr. This is pretty much standard behavior for modern compilers.
Nov 22 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/22/2016 8:07 AM, Steven Schveighoffer wrote:
 On 11/22/16 8:31 AM, Ilya Yaroshenko wrote:
 2. Why bsf and bsr do NOT use hardware instructions anymore?
They should unless there is no hardware instruction available. I believe the software implementation is only a fallback when this is the case.
That's correct.
Nov 22 2016
parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Wednesday, 23 November 2016 at 01:18:09 UTC, Walter Bright 
wrote:
 On 11/22/2016 8:07 AM, Steven Schveighoffer wrote:
 On 11/22/16 8:31 AM, Ilya Yaroshenko wrote:
 2. Why bsf and bsr do NOT use hardware instructions anymore?
They should unless there is no hardware instruction available. I believe the software implementation is only a fallback when this is the case.
That's correct.
Thank you for the confirmation!
Nov 22 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/22/2016 5:31 AM, Ilya Yaroshenko wrote:
 Please add a module (core.intrinsics ?) which will contain all DMD intrinsics
 similar to ldc.intrinsics. After each DMD release it is not clear what is
 intrinsics and what is not. I need BSF intrinsics for Better C library Mir
 Random [1], which should work without linking with DRuntime and Phobos. I can
 use ldc.intrinsics for LDC, but have no idea about DMD. I want BSR and BSF
 instructions to be generated instead of current _software_ implementation in
 core.bitop.

 ==================
 Philosophical Questions:

 1. Why hight level stuff like BitRange is in core.bitop, but not in
 std.bitmanip? If it should be in core, why it is public?

 2. Why bsf and bsr do NOT use hardware instructions anymore?
 ==================

 Please ping me for Phobos and DRuntime PRs if they are related to math and
 numeric issues.
The definitive list of dmd intrinsics is here: https://github.com/dlang/dmd/blob/master/src/toir.d#L349 It is definitive in the sense that it is what dmd actually does, rather than what any documentation says it does :-) There reason there isn't a specific core.intrinsics module is that essentially any function in the library could be made an intrinsic by an implementation, and it is up to the implementation to make such choices. Therefore, making a function an intrinsic should not necessitate moving its location. The bodies of 'intrinsic' functions exist to: 1. provide a reference implementation that documents what it does 2. provide a fallback if some implementation decides to not make it an intrinsic. Such decisions are left up to the implementation. 3. the bodies are needed if the address of an intrinsic function is taken. If an implementation does decide to make a certain function an intrinsic, the function is not referenced from the object file and the library does not need to be linked to. bsr and bsf are dmd intrinsics. It's easy enough to verify by running obj2asm on a dmd generated object file, and then grepping it for bsr/bsf instruction mnemonics.
Nov 22 2016
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 23/11/2016 1:46 PM, Walter Bright wrote:
 On 11/22/2016 5:31 AM, Ilya Yaroshenko wrote:
 Please add a module (core.intrinsics ?) which will contain all DMD
 intrinsics
 similar to ldc.intrinsics. After each DMD release it is not clear what is
 intrinsics and what is not. I need BSF intrinsics for Better C library
 Mir
 Random [1], which should work without linking with DRuntime and
 Phobos. I can
 use ldc.intrinsics for LDC, but have no idea about DMD. I want BSR and
 BSF
 instructions to be generated instead of current _software_
 implementation in
 core.bitop.

 ==================
 Philosophical Questions:

 1. Why hight level stuff like BitRange is in core.bitop, but not in
 std.bitmanip? If it should be in core, why it is public?

 2. Why bsf and bsr do NOT use hardware instructions anymore?
 ==================

 Please ping me for Phobos and DRuntime PRs if they are related to math
 and
 numeric issues.
The definitive list of dmd intrinsics is here: https://github.com/dlang/dmd/blob/master/src/toir.d#L349 It is definitive in the sense that it is what dmd actually does, rather than what any documentation says it does :-) There reason there isn't a specific core.intrinsics module is that essentially any function in the library could be made an intrinsic by an implementation, and it is up to the implementation to make such choices. Therefore, making a function an intrinsic should not necessitate moving its location. The bodies of 'intrinsic' functions exist to: 1. provide a reference implementation that documents what it does 2. provide a fallback if some implementation decides to not make it an intrinsic. Such decisions are left up to the implementation. 3. the bodies are needed if the address of an intrinsic function is taken. If an implementation does decide to make a certain function an intrinsic, the function is not referenced from the object file and the library does not need to be linked to. bsr and bsf are dmd intrinsics. It's easy enough to verify by running obj2asm on a dmd generated object file, and then grepping it for bsr/bsf instruction mnemonics.
Most of those intrinsics are in std.math. These things are why I failed to split std.math up. Pretty please can we get them moved out?
Nov 22 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-11-23 01:46, Walter Bright wrote:
 On 11/22/2016 5:31 AM, Ilya Yaroshenko wrote:
 Please add a module (core.intrinsics ?) which will contain all DMD
 intrinsics
 similar to ldc.intrinsics. After each DMD release it is not clear what is
 intrinsics and what is not. I need BSF intrinsics for Better C library
 Mir
 Random [1], which should work without linking with DRuntime and
 Phobos. I can
 use ldc.intrinsics for LDC, but have no idea about DMD. I want BSR and
 BSF
 instructions to be generated instead of current _software_
 implementation in
 core.bitop.

 ==================
 Philosophical Questions:

 1. Why hight level stuff like BitRange is in core.bitop, but not in
 std.bitmanip? If it should be in core, why it is public?

 2. Why bsf and bsr do NOT use hardware instructions anymore?
 ==================

 Please ping me for Phobos and DRuntime PRs if they are related to math
 and
 numeric issues.
The definitive list of dmd intrinsics is here: https://github.com/dlang/dmd/blob/master/src/toir.d#L349
There's builtin.d [1] as well. When is which one used? [1] https://github.com/dlang/dmd/blob/master/src/builtin.d -- /Jacob Carlborg
Nov 23 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 23 November 2016 at 15:29:48 UTC, Jacob Carlborg 
wrote:
 There's builtin.d [1] as well. When is which one used?
builtin is used for CTFE.
Nov 23 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-11-23 18:04, ketmar wrote:
 On Wednesday, 23 November 2016 at 15:29:48 UTC, Jacob Carlborg wrote:
 There's builtin.d [1] as well. When is which one used?
builtin is used for CTFE.
Aha, I see, thanks. -- /Jacob Carlborg
Nov 23 2016