This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
fix for cc0 targets and new jump
- To: gcc-patches at gcc dot gnu dot org, rth at cygnus dot com, patches at x86-64 dot org
- Subject: fix for cc0 targets and new jump
- From: Jan Hubicka <jh at suse dot cz>
- Date: Fri, 29 Jun 2001 11:41:23 +0200
Hi,
I am getting confident that CC0 targets will be unhappy about my new jump
pass, as I am not killing the cc0 setters. Unfortunately I don't have any
cc0 target to test, but following patch should do the trick.
Note that for tablejump, I may keep the computation there for a while, as I
kill only the jump instruction, not the index computed. Old jump pass is
messing arround with delete_computation, but this is also not very well
designed. Should I set flag and call delete_trivially_dead_insns (updated for
flowgraph) afterwards if converison happends, or do you think it is OK to just
ignore it?
Honza
Fri Jun 29 11:37:38 CEST 2001 Jan Hubicka <jh@suse.cz>
* flow.c (try_redirect_by_replacing_jump): Remove cc0 setter.
Index: flow.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/flow.c,v
retrieving revision 1.410
diff -c -3 -p -r1.410 flow.c
*** flow.c 2001/06/29 03:30:17 1.410
--- flow.c 2001/06/29 09:36:38
*************** try_redirect_by_replacing_jump (e, targe
*** 1707,1712 ****
--- 1707,1726 ----
else if (!fallthru && GET_CODE (barrier) != BARRIER)
emit_barrier_after (insn);
+ /* In case we've zapped an conditional jump, we need to kill the cc0
+ setter too if available. */
+ #ifdef HAVE_cc0
+ insn = src->end;
+ if (GET_CODE (insn) == JUMP_INSN)
+ insn = prev_nonnote_insn (insn);
+ if (sets_cc0_p (insn))
+ {
+ if (insn == src->end)
+ src->end = PREV_INSN (insn);
+ flow_delete_insn (insn);
+ }
+ #endif
+
if (e->dest != target)
redirect_edge_succ (e, target);
return true;