https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
--- Comment #10 from Andrew Pinski ---
With the fixed testcase we get:
movq%rsi, %rax
movq%rsi, %rcx
shrq$6, %rax
andl$63, %ecx
movq(%rdi,%rax,8), %rax
shrq%cl, %rax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
--- Comment #9 from Andrew Pinski ---
Note there is a bug in the original testcase.
It should be:
int test_bit(unsigned long *words, int bit)
{
int wsize = (sizeof *words) * 8;
return (words[bit / wsize] & (1ul << (bit % wsize))) != 0;
--- Comment #4 from avi at argo dot co dot il 2006-04-11 15:36 ---
Benchmark results, 32 bit code, various methods
On an athlon 64:
bts reg, (reg): 1 cycle
bts reg, (mem): 3 cycles
C code (reg):1 cycle
C code (mem):5 cycles
On a Xeon:
bts reg, (reg): 6
--- Comment #5 from avi at argo dot co dot il 2006-04-11 15:38 ---
Created an attachment (id=11243)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11243action=view)
benchmark for various set_bit() implementions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
--- Comment #6 from avi at argo dot co dot il 2006-04-11 15:39 ---
oops, the benchmark was for bts. will do again for bt.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
--- Comment #7 from avi at argo dot co dot il 2006-04-11 15:53 ---
Created an attachment (id=11244)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11244action=view)
bt instruction benchmark
redone the test for test_bit(), this time always forcing a memory access:
Athlon 64:
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-11 23:03 ---
Code size issue
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #2 from steven at gcc dot gnu dot org 2006-04-10 20:18 ---
The resulting code for -march=opteron:
test_bit:
.LFB2:
leal63(%rsi), %edx
testl %esi, %esi
movl%esi, %eax
cmovns %esi, %edx
sarl$31, %eax
shrl$26,
--- Comment #3 from steven at gcc dot gnu dot org 2006-04-10 20:31 ---
This is what the i386 machine description has to say about BT and friends:
;; %%% bts, btr, btc, bt.
;; In general these instructions are *slow* when applied to memory,
;; since they enforce atomic operation. When
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 15:33 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
10 matches
Mail list logo
