[Bug rtl-optimization/58681] New: Missed RTL optimization - same insns before unconditional jump as before the jump target

[jakub at gcc dot gnu.org]

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)?