Re: Flow analysis confused by exception handling

Re: Flow analysis confused by exception handling

[meissner]

| The schedulers rely on basic_block_{head,end} do delimit basic block
| boundaries.  Similarly for most passes after flow.

Just a reminder, this is true for the passes after flow and up to reload.
Reload seriously damages the flow information (insns created by reload that are
adjacent to basic blocks, won't be added to any basic block).

Re: Flow analysis confused by exception handling

[Jeffrey A Law]

  In message < 199712022112.VAA14078@phal.cygnus.co.uk >you write:
  > > Tue Dec  2 01:42:33 1997  Jason Merrill  <jason@yorick.cygnus.com>
  > > 
  > > 	* flow.c (find_basic_blocks): A CALL_INSN that can throw starts
  > > 	a new basic block.
  > > 	(find_basic_blocks_1): Likewise.
  > 
  > I think you have to fix some code in the schedulers when you do that.
I don't think so.

The schedulers rely on basic_block_{head,end} do delimit basic block
boundaries.  Similarly for most passes after flow.

jeff

Re: Flow analysis confused by exception handling

[Joern Rennecke]

> Tue Dec  2 01:42:33 1997  Jason Merrill  <jason@yorick.cygnus.com>
> 
> 	* flow.c (find_basic_blocks): A CALL_INSN that can throw starts
> 	a new basic block.
> 	(find_basic_blocks_1): Likewise.

I think you have to fix some code in the schedulers when you do that.

Re: Flow analysis confused by exception handling

[Jason Merrill]

>>>>> Teemu Torma <tot@trema.com> writes:

> The problem I sent few days ago about register being clobbered
> in sparc while throwing seems to be actually flow analysis problem.
> In the following code, the initial assignment to `i' gets deleted
> because the next instruction also assigns it.

Does this fix the problem?

Tue Dec  2 01:42:33 1997  Jason Merrill  <jason@yorick.cygnus.com>

	* flow.c (find_basic_blocks): A CALL_INSN that can throw starts
	a new basic block.
	(find_basic_blocks_1): Likewise.

Index: flow.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/flow.c,v
retrieving revision 1.100
diff -c -r1.100 flow.c
*** flow.c	1997/11/28 04:44:47	1.100
--- flow.c	1997/12/02 09:25:06
***************
*** 304,309 ****
--- 304,310 ----
    {
      register RTX_CODE prev_code = JUMP_INSN;
      register RTX_CODE code;
+     int eh_region = 0;
  
      max_uid_for_flow = 0;
  
***************
*** 316,322 ****
  	    || (GET_RTX_CLASS (code) == 'i'
  		&& (prev_code == JUMP_INSN
  		    || (prev_code == CALL_INSN
! 			&& nonlocal_label_list != 0)
  		    || prev_code == BARRIER)))
  	  i++;
  
--- 317,323 ----
  	    || (GET_RTX_CLASS (code) == 'i'
  		&& (prev_code == JUMP_INSN
  		    || (prev_code == CALL_INSN
! 			&& (nonlocal_label_list != 0 || eh_region))
  		    || prev_code == BARRIER)))
  	  i++;
  
***************
*** 325,330 ****
--- 326,335 ----
  
  	if (code != NOTE)
  	  prev_code = code;
+ 	else if (NOTE_LINE_NUMBER (insn) == NOTE_INSN_EH_REGION_BEG)
+ 	  ++eh_region;
+ 	else if (NOTE_LINE_NUMBER (insn) == NOTE_INSN_EH_REGION_END)
+ 	  --eh_region;
        }
    }
  
***************
*** 420,426 ****
  	       || (GET_RTX_CLASS (code) == 'i'
  		   && (prev_code == JUMP_INSN
  		       || (prev_code == CALL_INSN
! 			   && nonlocal_label_list != 0
  			   && ! find_reg_note (insn, REG_RETVAL, NULL_RTX))
  		       || prev_code == BARRIER)))
  	{
--- 425,431 ----
  	       || (GET_RTX_CLASS (code) == 'i'
  		   && (prev_code == JUMP_INSN
  		       || (prev_code == CALL_INSN
! 			   && (nonlocal_label_list != 0 || eh_note)
  			   && ! find_reg_note (insn, REG_RETVAL, NULL_RTX))
  		       || prev_code == BARRIER)))
  	{

Flow analysis confused by exception handling

[Teemu Torma]

The problem I sent few days ago about register being clobbered
in sparc while throwing seems to be actually flow analysis problem.
In the following code, the initial assignment to `i' gets deleted
because the next instruction also assigns it.

The rtl dump after the second cse looks like:

(insn 11 8 13 (set (reg/v:SI 105)
        (const_int 0)) 111 {*movsi_insn} (nil)
    (expr_list:REG_EQUAL (const_int 0)
        (nil)))

(note 13 11 15 13 NOTE_INSN_EH_REGION_BEG)

(note 15 13 17 "" NOTE_INSN_DELETED)

(note 17 15 19 "" NOTE_INSN_DELETED)

(call_insn 19 17 21 (parallel[ 
            (set (reg:SI 8 %o0)
                (call (mem:SI (symbol_ref:SI ("bar__Fv")))
                    (const_int 0)))
            (clobber (reg:SI 15 %o7))
        ] ) -1 (nil)
    (nil)
    (nil))

But after the flow analysis, the assignment to zero is gone:

(note 8 7 11 "" NOTE_INSN_DELETED)

;; Start of basic block 0, registers live: 14 [%sp] 30 [%fp] 31 [%i7]
(note 11 8 13 "" NOTE_INSN_DELETED)

(note 13 11 15 13 NOTE_INSN_EH_REGION_BEG)

(note 15 13 17 "" NOTE_INSN_DELETED)

(note 17 15 19 "" NOTE_INSN_DELETED)

(call_insn 19 17 21 (parallel[ 
            (set (reg:SI 8 %o0)
                (call (mem:SI (symbol_ref:SI ("bar__Fv")))
                    (const_int 0)))
            (clobber (reg:SI 15 %o7))
        ] ) -1 (nil)
    (expr_list:REG_UNUSED (reg:SI 15 %o7)
        (nil))
    (nil))

This would be right if bar wouldn't throw anything, but it is
clearly wrong because insn 19 does not actually assign anything.

Teemu

---------------------------------------------------------------------------
#include <stdio.h>

int bar ()
{
  throw 100;
}

main ()
{
  int i = 0;			// this gets deleted after flow analysis
  try
    {
      i = bar ();
    }
  catch (...)
    {
    }

  printf ("i = %d\n", i);
  return i;
}
---------------------------------------------------------------------------