This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PPC EH failure


Hi,
the scheduler in PPC construct:
;; Basic block 31, loop depth 0, count 0
;; Predecessors:  30 [50.0%]  (fallthru)
;; Registers live at start: 0 [0] 1 [1] 26 [26] 27 [27] 28 [28] 30 [30] 31 [31]
67 [ap]
(note 902 571 572 [bb 31] NOTE_INSN_BASIC_BLOCK)
(insn 572 902 1049 (set (mem/s/j:HI (plus:SI (reg/v/f:SI 26 r26 [195])
                (const_int 42 [0x2a])) [0 <variable>.vtable_method_count+0 S2 A16])
        (reg:HI 0 r0 [230])) 296 {*rs6000.md:7725} (nil)
    (expr_list:REG_DEAD (reg:HI 0 r0 [230])
        (expr_list:REG_EH_REGION (const_int 1 [0x1])
            (nil))))
(insn 1049 572 573 (use (symbol_ref:SI ("_ZN4java4lang6Object6class$E"))) -1 (nil)
    (nil))
;; Registers live at end: 1 [1] 26 [26] 27 [27] 28 [28] 30 [30] 31 [31] 67 [ap]
;; Successors:  32 [50.0%]  (fallthru) 78 [50.0%]  (ab,eh)

making my checking to fail.  It is obviously incorrect to move the use
after EH_REGION insn and sheduler already do contain code:
  /* If this instruction can throw an exception, then moving it changes
     where block boundaries fall.  This is mighty confusing elsewhere.
     Therefore, prevent such an instruction from being moved.  */
  if (can_throw_internal (insn))
    reg_pending_barrier = true;
that does care it, but it does not hit on use as it barriers only registers,
not the rest.  I am probably going to fix it by calling fixup_abnormal_edges,
but the question is whether this hunk should to go and whether such fix
is OK - it is definitly OK for local movement, but we should probably prevent
somewhere the global movement to avoid confussion.

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]