[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

["jakub at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #21 from jakub at gcc dot gnu dot org  2007-08-29 11:18 -------
The major difference between say i?86 or x86_64 and ppc here is that
on the former two the hard frame pointer is actually visibly, not just
artificially, used when restoring the stack pointer.  ppc restores the
stack pointer from the memory value stwux instruction creates and so it
doesn't visibly use hard frame pointer.
While rest_of_handle_ud_dce calls mark_artificial_uses and that way marks
all the instructions that define the artificial registers.  On the other
side, dce_process_block from fast_dce will not mark the instructions that
define the artificial uses, instead or all the artificial register bits into
local_live bitmap.
31 (ppc hard frame pointer) is an artificial use, so dce_process_block
sets bit 31 in local_live during initialization (i.e. at the end of the basic
block).  But then goes through insns backwards and finds
(insn 50 49 51 2 l2.c:9 (set (reg/f:DI 31 31)
        (mem/c:DI (plus:DI (reg/f:DI 1 1)
                (const_int -8 [0xfffffffffffffff8])) [5 S8 A8])) -1 (nil))
which restores the saved hard frame pointer in the epilogue.  This definition
clears bit 31 from the local_live bitmap and as everything is one basic block,
there is nothing else which will prevent removing the hard frame pointer
initialization.

df_simulate_one_insn_forwards and df_simulate_one_insn_backwards
(why we have the former when nothing ever uses it?) both call
df_simulate_fixup_sets to fix this up, shouldn't dce_process_block call that
too?


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dberlin at gcc dot gnu dot
                   |                            |org, bonzini at gnu dot org
           Priority|P3                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758