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

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

At 9:12 PM +0200 6/16/02, Hans-Peter Nilsson wrote:
>  > Date: Sun, 16 Jun 2002 09:08:26 -0400
>>  From: Alan Lehotsky <apl@alum.mit.edu>
>>  It would seem to me that having return patterns and having epilogues
>>  generated by the "old mechanism" is incompatible ANYWAY.
>Not by design, so it was a clear bug that it didn't work.
>>  Wouldn't it be better to use the DEFINE_EXPAND for "prologue" and
>>  "epilogue" to avoid this problem entirely?
>Not to paper over a bug, but yes, it's generally the preferred
>solution.  (Please keep in mind that the CRIS port predates
>prologue-and-epilogue as RTL.)
>>   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.
>Where are your bug-reports?

	I submitted patches on 'em...  AFAIK, all the problems I found are now
	fixed in mainline... I was just remarking that as rule, there have
	been a LOT of bugs in dealing with epilogue delay lists and 
avoiding them
	would be a good thing....

>>  Is there something particularly funky about the CRIS port that can't
>>  be handled by the new
>>  prolog/epilog mechanisms?
>Not really, but I'm inclined to not change the prologue, since
>it would probably break gdb; it parses the prologue code and
>assumes things about its structure.  That might not be an issue
>since the switch to using dwarf2 debugging, though.  Also, CRIS
>does not have any scheduling needs, so I saw no apparent
>performance win with having the prologue or epilogue as RTL.

	Shouldn't affect gdb's parsing unless it's REALLY simplistic, 
should it?  The
	"prologue" pattern should result in the same instructions 
you'd get with the
	functional version.

	I switched to new-style prolog/epilog for my ASIC port, it 
took me about two days,
	half of which was due to silly mistakes on my part.  It also 
let me generate
	significantly better code for some special cases that were 
really annoying to get right in
	function versions....

		    Quality Software Management
		          (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