This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA:] Fix PR rtl-optimization/19462 reorg: return andcurrent_function_epilogue_delay_list


On Tue, 2005-01-18 at 09:13 -0500, Hans-Peter Nilsson wrote:
> See the PR and also PR target/7042.  Xfailed test-case committed
> in gcc/testsuite/gcc.dg/torture/pr19462-1.c.
> 
> The problem is hopefully completely spelled out in the comment
> (assuming a reader familiar with this machinery): once
> current_function_epilogue_delay_list is non-null, any new
> non-exceptional return paths must also run the insns in
> current_function_epilogue_delay_list and the code wasn't caring
> for that being non-null.  However, moving those insns seems
> excessive for obsoleted functionality, so I'd prefer not
> creating the new return paths.  Making sure that return insns
> don't clash with current_function_epilogue_delay_list could be
> made the responsibility of the target, but why doing it for each
> target when it can be handled by the middle-end for known
> invalid cases?
> 
> I also seek comments (perhaps approval) regarding removing all
> traces of current_function_epilogue_delay_list and related
> macros on 4.1, because it's only used for textual epilogues, and
> we don't want them, right?  Particularly when this functionality
> has shown a tendency to attract bugs related to filling
> delay-slots of normal insns.
> 
> No regressions tested cross to cris-axis-linux-gnu, bootstrapped
> and checked native on sparc-sun-solaris2.8 (c,c++,java,objc)
> (which has delay-slots but doesn't have textual epilogues; it
> does use that framework, but only to output a nop in some rare
> cases).
> 
> Ok to commit?
> 
> 	PR rtl-optimization/19462
> 	* reorg.c (find_end_label): Create return insn only if
> 	current_function_epilogue_delay_list is empty.
OK.  I'm not entirely sure it fixes all the issues in this space, but
it ought to be safe.

As for killing current_function_epilogue_delay_list and its related
braindamanged -- go for it.  Only two ports use it (cris and arc), so
it shouldn't be a huge task. 

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]