Re: Fix for frame note handling under hppa-linux

[Olivier Hainque <hainque at ACT-Europe dot FR>]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:
> Are you trying DWARF2 with SOM?

 Yes. It seems to work pretty well, but part of the changes are not quite
 in submittable form yet.

 Also, at least one known problem with delay slots remains. See ...

 o http://gcc.gnu.org/ml/gcc-patches/2001-11.2/msg00037.html
   for a discussion of the problem and a first attempt to fix it.

 o http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00209.html
   for a discussion of troubles introduced by the initial fix and for
   a set of approaches to deal with it differently.

 o http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02333.html
   for an implementation hint related to the most popular of these
   approaches.

> >  We had to deal with parallels in a specific way, as mentioned in the
> >  thread started at

> Needs to be checked.  Do you have a patch?

 For this specific point, we currently have something like what follows.
 I don't think the FRP/DEEP_FRP differentiation is necessary though.

*** config/pa/pa.c.ori	Wed Feb  6 16:16:39 2002
--- config/pa/pa.c	Wed Feb  6 18:41:16 2002
***************
*** 56,72 ****
  #endif
  
  #if DO_FRAME_NOTES
! #define FRP(INSN) \
!   do					\
!     {					\
!       rtx insn = INSN;			\
!       RTX_FRAME_RELATED_P (insn) = 1;	\
!     }					\
!   while (0)
  #else
  #define FRP(INSN) INSN
  #endif
  
  #ifndef FUNC_BEGIN_PROLOG_LABEL
  #define FUNC_BEGIN_PROLOG_LABEL        "LFBP"
  #endif
--- 56,98 ----
  #endif
  
  #if DO_FRAME_NOTES
! 
! static rtx mark_frp PARAMS ((rtx, int));
! 
! static rtx mark_frp (insn, go_down)
!      rtx insn;
!      int go_down;
! {
!   rtx pattern = PATTERN (insn);
! 
!   RTX_FRAME_RELATED_P (insn) = 1;
! 
!   if (go_down
!       && (GET_CODE (pattern) == PARALLEL
! 	  || GET_CODE (pattern) == SEQUENCE))
!     {                                
!       int par_index;                 
!       int limit = XVECLEN (pattern, 0); 
!       
!       for (par_index = 0; par_index < limit; par_index++) 
! 	{                                                 
! 	  rtx x = XVECEXP (pattern, 0, par_index);           
! 	  RTX_FRAME_RELATED_P (x) = 1;	              
! 	}
!     }
!   
!   return insn;
! }
! 
! #define FRP(INSN) mark_frp (INSN, 0)
! #define DEEP_FRP(INSN) mark_frp (INSN, 1)
! 
  #else
  #define FRP(INSN) INSN
+ #define DEEP_FRP(INSN) INSN
  #endif
  
+ 
  #ifndef FUNC_BEGIN_PROLOG_LABEL
  #define FUNC_BEGIN_PROLOG_LABEL        "LFBP"
  #endif
***************
*** 3254,3262 ****
  	      {
  		rtx delta = GEN_INT (-offset);
  		merge_sp_adjust_with_store = 0;
! 	        FRP (emit_insn (gen_post_store (stack_pointer_rtx,
! 						gen_rtx_REG (word_mode, i),
! 						delta)));
  	      }
  	    else
  	      store_reg (i, offset, STACK_POINTER_REGNUM);
--- 3355,3364 ----
  	      {
  		rtx delta = GEN_INT (-offset);
  		merge_sp_adjust_with_store = 0;
! 	        DEEP_FRP (emit_insn
! 			  (gen_post_store (stack_pointer_rtx,
! 					   gen_rtx_REG (word_mode, i),
! 					   delta)));
  	      }
  	    else
  	      store_reg (i, offset, STACK_POINTER_REGNUM);


> I see your message has a test program.

 Yes. The goal is to force a situation in which we get to the gen_post_store
 to have a parallel generated. This might also be OBE due to changes elsewhere
 in the dwarf2out circuitry, but I don't believe so.

> >  More precisely, isn't "offset" from the frame pointer instead of the stack
> >  pointer when frame_pointer_needed is true ?
> 
> Yes, thanks for spotting this.  I must admit that when I started trying
> to get 3.1 working on hppa-linux there were a number of bootstrap issues
> and gdb didn't work.  I was pretty excited to get backtraces from gdb that
> seemed for the most part reasonable.

 Sure I understand that :)

 Thanks for your feedback.

 Kind Regards,

 Olivier