Bug 4046 – [CTFE] std.intrinsic

Status
RESOLVED
Resolution
WONTFIX
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2010-04-02T14:25:00Z
Last change time
2015-06-09T05:11:50Z
Keywords
rejects-valid
Assigned to
nobody
Creator
bearophile_hugs

Comments

Comment #0 by bearophile_hugs — 2010-04-02T14:25:39Z
import std.intrinsic: bt; int foo() { uint x = uint.max; return bt(&x, 5); } int _ = foo(); void main() {} dmd 2.042 gives: test.d(4): Error: cannot evaluate bt((& x),5u) at compile time test.d(6): Error: cannot evaluate foo() at compile time test.d(6): Error: cannot evaluate foo() at compile time In CTFE the the compiler can replace the intrinsics with little functions with the same semantics.
Comment #1 by clugdbug — 2011-09-22T06:27:33Z
I'm not sure why the btXX functions (bt, btc, btr, etc) exist at all. Although they are a single instruction, they are MUCH slower than the equivalent code using shifts or AND/OR/XOR. For example, on Core i7 (Sandy Bridge), with a memory operand, they take 6 clock cycles!!!! You can execute 24 integer instructions in that time. On AMD K10, they're even slower. On Pentium 4 they have a latency of EIGHTEEN clock cycles. They're even slow on VIA processors as well -- they're not good anywhere. I think they should be completely removed. There's a case for the intrinsics mentioned in bug 5703, but I think this should be a WONTFIX. To support them would just encourage slow, non-portable code.
Comment #2 by dmitry.olsh — 2011-09-22T10:42:25Z
(In reply to comment #1) > I'm not sure why the btXX functions (bt, btc, btr, etc) exist at all. > Although they are a single instruction, they are MUCH slower than the > equivalent code using shifts or AND/OR/XOR. > For example, on Core i7 (Sandy Bridge), with a memory operand, they take 6 > clock cycles!!!! You can execute 24 integer instructions in that time. On AMD > K10, they're even slower. On Pentium 4 they have a latency of EIGHTEEN clock > cycles. They're even slow on VIA processors as well -- they're not good > anywhere. Damn, and I used them at heart of important loops in FReD .... Thanks, I'm getting rid of them ASAP %) This should be probably mentioned somewhere, and then there are these problematic bsr/bsf you mentioned before. > > I think they should be completely removed. There's a case for the intrinsics > mentioned in bug 5703, but I think this should be a WONTFIX. To support them > would just encourage slow, non-portable code.
Comment #3 by bearophile_hugs — 2011-09-24T18:29:33Z
(In reply to comment #1) > I think they should be completely removed. There's a case for the intrinsics > mentioned in bug 5703, but I think this should be a WONTFIX. To support them > would just encourage slow, non-portable code. OK, then I close this But I suggest you to open an "enhancement" request that asks to deprecate the useless/bad intrinsics :-)