Re: Non-call exceptions versus cse

[Andrew Haley <aph at redhat dot com>]

Richard Kenner writes:
 >     bb0:
 >       p63 <= 0
 >       p65 <= [p63 + 4] ; can_trap to bb ??
 >     bb1:
 >       p61 <= p65
 >     
 >     > And after CSE:
 > 
 >     bb0:
 >       p61 <= [4] ; can_trap to bb ??
 >     bb1:
 > 
 > I don't think we'll do that.  This moves the assignment of p61 and I don't
 > think that happens.

This is the RTL in question before CSE:

   (note 27 22 28 0 ("Array_3.java") 64)
   
   (insn 28 27 30 0 0x40228554 (set (reg/v/f:SI 63)
           (const_int 0 [0x0])) -1 (nil)
       (nil))
   
   (note 30 28 33 0 ("Array_3.java") 66)
   
   (insn 33 30 233 0 0x402284a4 (set (reg/v:SI 65)
           (mem/s:SI (plus:SI (reg/v/f:SI 63)
                   (const_int 4 [0x4])) [15 <variable>.length+0 S4 A32])) -1 (nil)
       (expr_list:REG_EH_REGION (const_int 1 [0x1])
           (nil)))
   ;; End of basic block 0, registers live:
    (nil)
   
   ;; Start of basic block 1, registers live: (nil)
   (note 233 33 35 1 [bb 1] NOTE_INSN_BASIC_BLOCK)
   
   (insn 35 233 39 1 0x40228554 (set (reg/v:SI 61)
           (reg/v:SI 65)) -1 (nil)
       (nil))
   
And after CSE:

   (note 27 22 30 0 ("Array_3.java") 64)
   
   (note 30 27 33 0 ("Array_3.java") 66)
   
   (insn 33 30 233 0 0x402284a4 (set (reg/v:SI 61)
           (mem/s:SI (const_int 4 [0x4]) [15 <variable>.length+0 S4 A32])) 38 {*movsi_1} (nil)
       (expr_list:REG_EH_REGION (const_int 1 [0x1])
           (nil)))
   ;; End of basic block 0, registers live:
    (nil)
   
   ;; Start of basic block 1, registers live: (nil)
   
 > What would happen is that the p61 assignment would
 > become the trapping insn, which would move the trap to a different block.
 > That may or may not be OK.
 > 
 >     If CSEing an instruction which might throw with a subsequent insn is
 >     incorrect, then this patch will prevent that incorrect behaviour.  It
 >     won't affect anything other than this special case, as far as I can
 >     see.  Perhaps I'm misunderstanding the code.
 > 
 > I think you are.  The point isn't that there's a basic block boundary
 > there, but that p65 can trap.

Well, what other than a trapping insn might cause the basic block
boundary?

a. The current BB begins with a label: in that case my patch won't
make any difference, because the subsequent code is conditional on
GET_CODE (prev) == INSN.

b. The previous BB ends with a jump: in that case my patch won't make
any difference for the same reason.

Andrew.