On 10/29/2011 09:17 PM, Tom de Vries wrote:
> 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?
> 

Bootstrapped and reg-tested on x86_64.

Ok for trunk?

Thanks,
- Tom

> Thanks,
> - Tom
> 
> 2011-10-29  Tom de Vries  <t...@codesourcery.com>
> 
>       PR rtl-optimization/50764
>       * (sched_analyze_insn): Make sure frame-related insns are not moved past
>       preceding jump.
> 
> 
> 

Reply via email to