public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/31170] New: cmpxchgq not emitted.
@ 2007-03-14 9:59 pluto at agmk dot net
2007-03-14 11:00 ` [Bug rtl-optimization/31170] " rguenth at gcc dot gnu dot org
2007-03-14 19:05 ` pluto at agmk dot net
0 siblings, 2 replies; 3+ messages in thread
From: pluto at agmk dot net @ 2007-03-14 9:59 UTC (permalink / raw)
To: gcc-bugs
long emit_cmpxchg( long volatile* p, long from, long to )
{
long v = *p;
if ( v == from )
*p = to;
return v;
}
gcc should be able to optimize this.
--
Summary: cmpxchgq not emitted.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31170
^ permalink raw reply [flat|nested] 3+ messages in thread* [Bug rtl-optimization/31170] cmpxchgq not emitted.
2007-03-14 9:59 [Bug other/31170] New: cmpxchgq not emitted pluto at agmk dot net
@ 2007-03-14 11:00 ` rguenth at gcc dot gnu dot org
2007-03-14 19:05 ` pluto at agmk dot net
1 sibling, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2007-03-14 11:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-14 11:00 -------
ifcvt could do this. But is cmpxchgq really faster with its atomictiy
guarantee?
They are all vector-path instructions, a compare - cmov sequence looks
faster (8 cycle latency vs. 10 and also with less constraints on register
allocation). Even the code we emit now:
emit_cmpxchg:
.LFB2:
movq (%rdi), %rax
cmpq %rsi, %rax
je .L6
rep ; ret
.p2align 4,,7
.L6:
movq %rdx, (%rdi)
ret
could be faster dependent on branch probability.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|other |rtl-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31170
^ permalink raw reply [flat|nested] 3+ messages in thread* [Bug rtl-optimization/31170] cmpxchgq not emitted.
2007-03-14 9:59 [Bug other/31170] New: cmpxchgq not emitted pluto at agmk dot net
2007-03-14 11:00 ` [Bug rtl-optimization/31170] " rguenth at gcc dot gnu dot org
@ 2007-03-14 19:05 ` pluto at agmk dot net
1 sibling, 0 replies; 3+ messages in thread
From: pluto at agmk dot net @ 2007-03-14 19:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from pluto at agmk dot net 2007-03-14 19:05 -------
(In reply to comment #1)
> ifcvt could do this. But is cmpxchgq really faster with its atomictiy
> guarantee?
only `lock; cmpxchg' has atomicity guarantee on smp.
> They are all vector-path instructions, a compare - cmov sequence looks
> faster (8 cycle latency vs. 10 and also with less constraints on register
> allocation). Even the code we emit now:
>
> emit_cmpxchg:
> .LFB2:
> movq (%rdi), %rax
> cmpq %rsi, %rax
> je .L6
> rep ; ret
> .p2align 4,,7
> .L6:
> movq %rdx, (%rdi)
> ret
>
> could be faster dependent on branch probability.
yes, it could be faster, but for -Os we could emit
a small branchless code:
movq %rsi, %rax
cmpxchgq %rdx, (%rdi)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31170
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-03-14 19:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-14 9:59 [Bug other/31170] New: cmpxchgq not emitted pluto at agmk dot net
2007-03-14 11:00 ` [Bug rtl-optimization/31170] " rguenth at gcc dot gnu dot org
2007-03-14 19:05 ` pluto at agmk dot net
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).