http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58681
Bug ID: 58681
Summary: Missed RTL optimization - same insns before
unconditional jump as before the jump target
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org, rth at gcc dot gnu.org
While looking at PR58670 workaround, I've noticed we don't optimize very well:
int
foo (int a, int b)
{
int c, d, e, f;
if (a < 9)
{
c = -3;
d = -1;
e = -20;
f = -5;
}
else
{
asm volatile goto ("bts $1, %0; jc %l[lab]" : : "m" (b) : "memory" :
lab);
asm ("");
c = 0;
d = 12;
e = 26;
f = 7;
goto l;
lab:
c = 0;
d = 12;
e = 26;
f = 7;
l:;
}
return bar (bar (bar (c, d), e), f);
}
e.g. at -O0, the 4 assignments are the same right above a code label to which
an unconditional jump jumps and above the unconditional jump. If we detected
that, we could remove the 4 assignments from the second bb and just adjust the
unconditional jump to jump before the 4 assignments instead of after them.
Perhaps then even cfg cleanup would optimize away the jump (from asm goto) to
just an unconditional jump elsewhere. Note that if a < 9 in the testcase
above is replaced with just a, then the insns are the same only before
postreload, postreload then figures out that the %rdi already contains 0 and
changes it, but apparently just in ebb and not in other bbs.
Could this optimization be perhaps performed before reload (or both before and
after)?
