public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/38544] New: missed opportunity to use adc
@ 2008-12-16 21:56 rrh at google dot com
2008-12-16 21:59 ` [Bug rtl-optimization/38544] " pinskia at gcc dot gnu dot org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: rrh at google dot com @ 2008-12-16 21:56 UTC (permalink / raw)
To: gcc-bugs
The optimizer at -O3 for x86_64 finds opportunities to generate the "adc" (add
with carry) instruction to avoid a conditional branch. However, the dst of the
adc can only be in a register. The optimizer misses a chance to use "adc" with
the destination in memory, and will instead use a conditional branch in a
straightforward manner. The following program shows that foo1 uses adc, but
foo0 does not.
Although I haven't tested this, I'm sure that the other 3 possibilities in this
family (involving sbb and/or different literal values to add/subtract) will
also not find the opportunity to do a memory update with adc.
extern void consumep(int *);
extern void consume(int);
void foo0(unsigned a, unsigned b, int *victim)
{
if (a > b) { (*victim)++; }
consumep(victim);
}
void foo1(unsigned a, unsigned b, int victim)
{
if (a > b) { victim++; }
consume(victim);
}
--
Summary: missed opportunity to use adc
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rrh at google dot com
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38544
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug rtl-optimization/38544] missed opportunity to use adc
2008-12-16 21:56 [Bug rtl-optimization/38544] New: missed opportunity to use adc rrh at google dot com
@ 2008-12-16 21:59 ` pinskia at gcc dot gnu dot org
2008-12-17 8:57 ` [Bug target/38544] " ubizjak at gmail dot com
2008-12-17 9:01 ` [Bug rtl-optimization/38544] " ubizjak at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-12-16 21:59 UTC (permalink / raw)
To: gcc-bugs
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Keywords| |missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38544
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug target/38544] missed opportunity to use adc
2008-12-16 21:56 [Bug rtl-optimization/38544] New: missed opportunity to use adc rrh at google dot com
2008-12-16 21:59 ` [Bug rtl-optimization/38544] " pinskia at gcc dot gnu dot org
@ 2008-12-17 8:57 ` ubizjak at gmail dot com
2008-12-17 9:01 ` [Bug rtl-optimization/38544] " ubizjak at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: ubizjak at gmail dot com @ 2008-12-17 8:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from ubizjak at gmail dot com 2008-12-17 08:56 -------
There are various scary comments in ifcvt.c, noce_process_if_block() regarding
memory operands, like:
/* Only operate on register destinations, and even then avoid extending
the lifetime of hard registers on small register class machines. */
and
/* Don't operate on sources that may trap or are volatile. */
and
/* Avoid store speculation: given "if (...) x = a" where x is a
MEM, we only want to do the store if x is always set
somewhere in the function. This avoids cases like
if (pthread_mutex_trylock(mutex))
++global_variable;
where we only want global_variable to be changed if the mutex
is held. FIXME: This should ideally be expressed directly in
RTL somehow. */
I don't think it is always safe to simplify global memory operands.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38544
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug rtl-optimization/38544] missed opportunity to use adc
2008-12-16 21:56 [Bug rtl-optimization/38544] New: missed opportunity to use adc rrh at google dot com
2008-12-16 21:59 ` [Bug rtl-optimization/38544] " pinskia at gcc dot gnu dot org
2008-12-17 8:57 ` [Bug target/38544] " ubizjak at gmail dot com
@ 2008-12-17 9:01 ` ubizjak at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: ubizjak at gmail dot com @ 2008-12-17 9:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from ubizjak at gmail dot com 2008-12-17 08:58 -------
Setting Component to Generic RTL optimization.
--
ubizjak at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|target |rtl-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38544
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-12-17 9:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-12-16 21:56 [Bug rtl-optimization/38544] New: missed opportunity to use adc rrh at google dot com
2008-12-16 21:59 ` [Bug rtl-optimization/38544] " pinskia at gcc dot gnu dot org
2008-12-17 8:57 ` [Bug target/38544] " ubizjak at gmail dot com
2008-12-17 9:01 ` [Bug rtl-optimization/38544] " ubizjak at gmail dot com
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).