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

Hans-Peter Nilsson hans-peter.nilsson@axis.com
Sun Jun 16 12:12:00 GMT 2002


> 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?

> 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.

On the other hand, there are cleanup wins (and now-apparent
delay-slot wins) with having the epilogue as RTL, and gdb
couldn't care less about the epilogue AFAIK, so that seems
worthwhile.  Unless there's a problem with the asymmetric
prologue=text epilogue=rtl, of course.  But since there are no
documented restrictions on that, it should work; I guess I'll
find out.  Later, though.

brgds, H-P



More information about the Gcc-patches mailing list