[RFA:] reorg.c: fix target/7041 for main trunk

Alan Lehotsky apl@alum.mit.edu
Sun Jun 16 06:11:00 GMT 2002


It would seem to me that having return patterns and having epilogues 
generated by the "old mechanism" is incompatible ANYWAY.

Wouldn't it be better to use the DEFINE_EXPAND for "prologue" and 
"epilogue" to avoid this problem entirely?  I've encountered a number 
of nasty little buglets involving the 
current_function_epilogue_delay_list, and the numerous places that 
either FORGOT to check the list at all, or walked the list 
incorrectly.

Is there something particularly funky about the CRIS port that can't 
be handled by the new
prolog/epilog mechanisms?

-- Al

At 4:55 AM +0200 6/16/02, Hans-Peter Nilsson wrote:
>See also
><URL:http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01347.html>.
>There seems to be consensus that TRT to do for reorg is to
>actually rewrite it to use dependency graphs
>(<URL:http://gcc.gnu.org/ml/gcc-bugs/2002-06/msg00113.html>).
>No rewrite today though, just a simple correctness patch for the
>existing code.  Again, the only port with both epilogue delay
>slots and return patterns on the main trunk is CRIS, so there
>was little use testing this code on any other target.  Fixes
>gcc.c-torture/execute/20020615-1.c and libstdc++-v3
>27_io/stringbuf.cc for cris-*-* (e.g. cris-axis-elf).
>
>Ok to commit?
>
>	PR target/7041
>	* reorg.c (make_return_insns) [DELAY_SLOTS_FOR_EPILOGUE]: Exit
>	early if current_function_epilogue_delay_list is non-empty.
>
>Index: reorg.c
>===================================================================
>RCS file: /cvs/gcc/gcc/gcc/reorg.c,v
>retrieving revision 1.79
>diff -p -c -r1.79 reorg.c
>*** reorg.c	11 Jun 2002 12:22:13 -0000	1.79
>--- reorg.c	16 Jun 2002 00:57:58 -0000
>*************** make_return_insns (first)
>*** 3485,3490 ****
>--- 3485,3501 ----
>     rtx real_return_label = end_of_function_label;
>     int slots, i;
>
>+ #ifdef DELAY_SLOTS_FOR_EPILOGUE
>+   /* If a previous pass filled delay slots in the epilogue, things get a
>+      bit more complicated, as those filler insns would generally (without
>+      data flow analysis) have to be executed after any existing branch
>+      delay slot filler insns.  It is also unknown whether such a
>+      transformation would actually be profitable.  Note that the existing
>+      code only cares for branches with (some) filled delay slots.  */
>+   if (current_function_epilogue_delay_list != NULL)
>+     return;
>+ #endif
>+
>     /* See if there is a RETURN insn in the function other than the one we
>        made for END_OF_FUNCTION_LABEL.  If so, set up anything we can't change
>        into a RETURN to jump to it.  */
>
>brgds, H-P


-- 
		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
		          apl@alum.mit.edu
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation



More information about the Gcc-patches mailing list