[PR50764, PATCH] Fix for ICE in maybe_record_trace_start with -fsched2-use-superblocks

[Tom de Vries]

Richard,

I have a tentative fix for PR50764.

In the example from the test-case, -fsched2-use-superblocks moves an insn from
block 4 to block 3.

           2
          bar
           |
    -------+-----
   /             \
  *               *
  5 *------------ 3
abort            bar
                  |
                  |
                  *
                  4
                return


The insn has a REG_CFA_DEF_CFA note and is frame-related.
...
(insn/f 51 50 52 4 (set (reg:DI 39 r10)
        (mem/c:DI (plus:DI (reg/f:DI 6 bp)
                (const_int -8 [0xfffffffffffffff8])) [3 S8 A8])) pr50764.c:13
62 {*movdi_internal_rex64}
     (expr_list:REG_CFA_DEF_CFA (reg:DI 39 r10)
        (nil)))
...

This causes the assert in maybe_record_trace_start to trigger:
...
      /* We ought to have the same state incoming to a given trace no
	 matter how we arrive at the trace.  Anything else means we've
	 got some kind of optimization error.  */
      gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row));
...

The assert does not occur with -fno-tree-tail-merge, but that is due to the
following:
- -fsched-use-superblocks does not handle dead labels explicitly
- -freorder-blocks introduces a dead label, which is not removed until after
  sched2
- -ftree-tail-merge makes a difference in which block -freorder-blocks
  introduces the dead label. In the case of -ftree-tail-merge, the dead label
  is introduced at the start of block 3, and block 3 and 4 end up in the same
  ebb. In the case of -fno-tree-tail-merge, the dead label is introduced at the
  start of block 4, and block 3 and 4 don't end up in the same ebb.

attached untested patch fixes PR50764 in a similar way as the patch for PR49994,
which is also about an ICE in maybe_record_trace_start with
-fsched2-use-superblocks.

The patch for PR49994 makes sure frame-related instructions are not moved past
the following jump.

Attached patch makes sure frame-related instructions are not moved past the
preceding jump.

Is this the way to fix this PR?

Thanks,
- Tom

2011-10-29  Tom de Vries  <tom@codesourcery.com>

	PR rtl-optimization/50764
	* (sched_analyze_insn): Make sure frame-related insns are not moved past
	preceding jump.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr50764.patch
Type: text/x-patch
Size: 730 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20111029/9577e322/attachment.bin>