digitalmars.D.bugs - [Issue 4046] New: [CTFE] std.intrinsic
- d-bugmail puremagic.com (30/30) Apr 02 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4046
- d-bugmail puremagic.com (16/16) Sep 22 2011 http://d.puremagic.com/issues/show_bug.cgi?id=4046
- d-bugmail puremagic.com (14/26) Sep 22 2011 http://d.puremagic.com/issues/show_bug.cgi?id=4046
- d-bugmail puremagic.com (14/17) Sep 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=4046
http://d.puremagic.com/issues/show_bug.cgi?id=4046 Summary: [CTFE] std.intrinsic Product: D Version: future Platform: x86 OS/Version: Windows Status: NEW Keywords: rejects-valid Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: bearophile_hugs eml.cc 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4046 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 22 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4046 Dmitry Olshansky <dmitry.olsh gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry.olsh gmail.com 10:42:25 PDT ---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.-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 22 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4046 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIXI 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 :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 24 2011