Committed, PR target/85666 1/2, MMIX: Don't call leaf_function_p

Message ID
State New
Headers show
  • Committed, PR target/85666 1/2, MMIX: Don't call leaf_function_p
Related show

Commit Message

Hans-Peter Nilsson Sept. 9, 2018, 6:18 p.m.
It's IMO never a good idea to call leaf_function_p in port-specific
code.  Sooner or later, you'll need that information in a context
where calling leaf_function_p is either a bad idea (it does a linear
walk over all emitted insns in a function) or invalid (called when
global context is within a sequence), like here.  I kind of knew that,
just bad judgement. :)  Better find out leaffunctionness some other
way, and/or stash it in a field in cfun->machine.

There's one more patch needed for PR85666, to bring back
mmix-knuth-mmixware to a buildable state.

	PR target/85666
	* config/mmix/mmix.c (MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS): Don't
	call leaf_function_p, instead use has_hard_reg_initial_val.

brgds, H-P


Index: gcc/config/mmix/mmix.c
--- gcc/config/mmix/mmix.c	(revision 264163)
+++ gcc/config/mmix/mmix.c	(working copy)
@@ -60,19 +60,16 @@ 

 /* We have no means to tell DWARF 2 about the register stack, so we need
    to store the return address on the stack if an exception can get into
-   this function.  FIXME: Narrow condition.  Before any whole-function
-   analysis, df_regs_ever_live_p () isn't initialized.  We know it's up-to-date
-   after reload_completed; it may contain incorrect information some time
-   before that.  Within a RTL sequence (after a call to start_sequence,
-   such as in RTL expanders), leaf_function_p doesn't see all insns
-   (perhaps any insn).  But regs_ever_live is up-to-date when
-   leaf_function_p () isn't, so we "or" them together to get accurate
-   information.  FIXME: Some tweak to leaf_function_p might be
-   preferable.  */
+   this function.  We'll have an "initial value" recorded for the
+   return-register if we've seen a call instruction emitted.  This note
+   will be inaccurate before instructions are emitted, but the only caller
+   at that time is looking for modulo from stack-boundary, to which the
+   return-address does not contribute, and which is always 0 for MMIX
+   anyway.  Beware of calling leaf_function_p here, as it'll abort if
+   called within a sequence.  */
  (flag_exceptions						\
-  && ((reload_completed && df_regs_ever_live_p (MMIX_rJ_REGNUM))	\
-      || !leaf_function_p ()))
+  && has_hard_reg_initial_val (Pmode, MMIX_INCOMING_RETURN_ADDRESS_REGNUM))

  (crtl->calls_eh_return		\