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