https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #20 from Andrew Pinski ---
I think most of these have been fixed. For an example comment #19 was fixed in
r12-1525
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #19 from H.J. Lu ---
For
---
int
foo1 (int x, int y)
{
x &= 1 << y;
return x != 0;
}
---
combine fails to try
(set (reg:CCZ 17 flags)
(compare:CCZ (and:SI (lshiftrt:SI (reg/v:SI 88 [ x ])
(subreg:QI (reg/v:SI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
H.J. Lu changed:
What|Removed |Added
Attachment #31974|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #17 from H.J. Lu ---
Created attachment 31974
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31974&action=edit
A micro-benchmark for BTS with register
BTS with register operand is about 7-20% faster on Silvermont
an Haswell.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #16 from H.J. Lu ---
I couldn't get GCC to use those BT patterns:
(define_insn "*btsq"
[(set (zero_extract:DI (match_operand:DI 0 "register_operand" "+r")
(const_int 1)
(match_operan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #15 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #14)
> From i386.md:
>
> ;; %%% bts, btr, btc, bt.
> ;; In general these instructions are *slow* when applied to memory,
> ;; since they enforce atomic operation. When applie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #14 from Uroš Bizjak ---
From i386.md:
;; %%% bts, btr, btc, bt.
;; In general these instructions are *slow* when applied to memory,
;; since they enforce atomic operation. When applied to registers,
;; it depends on the cpu implemen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #13 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #8)
>
> I expect:
>
> bts %edi, bar2(%rip)
Did you see Comment #3?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #12 from H.J. Lu ---
For
int bar1;
void
__attribute__((noinline))
foo1 (int y)
{
int z;
if (!(bar1 & (1 << y)))
xxx1 ();
z = bar1 & (1 << y);
bar1 |= 1 << y;
bar1 &= ~z;
}
we generate
movlbar1(%rip), %edx
p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #11 from H.J. Lu ---
For
int bar1;
void
__attribute__((noinline))
foo1 (int y)
{
if ((bar1 & (1 << y)))
bar1 &= ~(1 << y);
}
we generate
.cfi_startproc
movlbar1(%rip), %eax
btl%edi, %eax
jnc.L1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #10 from H.J. Lu ---
For
int bar1;
void
__attribute__((noinline))
foo1 (int y)
{
if ((bar1 & (1 << y)))
{
bar1 &= ~(1 << y);
xxx1 ();
}
}
we generate
movlbar1(%rip), %eax
btl%edi, %eax
jc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #9 from H.J. Lu ---
For
int bar1;
void
__attribute__((noinline))
foo1 (int y)
{
if (!(bar1 & (1 << y)))
{
bar1 |= 1 << y;
xxx1 ();
}
}
we generate
.cfi_startproc
movlbar1(%rip), %eax
btl%edi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #8 from H.J. Lu ---
For
int bar1;
void
__attribute__((noinline))
foo1 (int y)
{
if (!(bar1 & (1 << y)))
bar1 |= 1 << y;
}
we generate
movlbar1(%rip), %eax
btl%edi, %eax
jc.L1
movl$1, %edx
mo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #7 from H.J. Lu ---
For
int
__attribute__((noinline))
foo1 (int x, int y)
{
x &= ~(1 << y);
return x;
}
we generate
movl%esi, %ecx
movl$-2, %eax
roll%cl, %eax
andl%edi, %eax
ret
I expect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #6 from H.J. Lu ---
For
int
__attribute__((noinline))
foo1 (int x, int y)
{
int z;
z = x & (1 << y);
x |= 1 << y;
x &= ~z;
return x;
}
we generate:
movl%esi, %ecx
movl$1, %edx
sall%cl, %edx
movl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #5 from H.J. Lu ---
For
int
__attribute__((noinline))
foo1 (int x, int y)
{
x &= (1 << y);
return x != 0;
}
we generate
movl%esi, %ecx
movl$1, %eax
sall%cl, %eax
testl%edi, %eax
setne%al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #3 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #0)
> There are some BT patterns in i386 guarded with
> TARGET_USE_BT. But there are no testcases to show
> if they are used at all.
testsuite/gcc.target/i386/bt-*.c
> Also B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
--- Comment #4 from Uroš Bizjak ---
The conversion to bt is somewhat fragile ATM, implemented with various
splitters.
There was discussion to represent bit-test instructions with its own RTX, with
the intention to generate them from middle-end i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59968
H.J. Lu changed:
What|Removed |Added
CC||areg.melikadamyan at gmail dot
com
20 matches
Mail list logo
