Re: [RFA] rs6000-tdep.c: Improve prologue handling with code motion.

["Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>]

It does work without the section.
I just added it to avoid unnecessary additional slow remote target reads,
which had always been a concern in the past.

I wanted to make sure that my patches don't add extra overhead in the
usual case (have line number info), and that we don't try to second
guess the information from the compiler. In addition it minimizes the
impact of the change (the old code did unconditionally break out of the
loop as well if a non-prologue insn was encountered).

I could leave the section out, but I'd appreciate if you could provide
an example to prove that it should be left out.

> On Nov 5,  2:12pm, Peter.Schauer wrote:
> 
> > 	* rs6000-tdep.c (skip_prologue):  Handle optimizer code motions into
> > 	the prologue by continuing the prologue search, if we have no valid
> > 	frame yet or if the return address is not yet saved in the frame.
> 
> [...]
> 
> > ! 	  if (num_skip_non_prologue_insns == 0 && lim_pc == 0)
> > ! 	    {
> > ! 	      /* Stop scan if we are looking for the end of the prologue
> > ! 		 and we have line numbers for the function
> > ! 		 The current result is good enough, and the compiler will
> > ! 		 hopefully help us to get better results via the line number
> > ! 		 info.  */
> > ! 	      struct symtab_and_line sal;
> > ! 	      sal = find_pc_line (pc, 0);
> > ! 	      if (sal.line != 0)
> > ! 		break;
> > ! 	    }
> 
> Does your patch still work without the above section?
> 
> It concerns me because I had to remove some similar looking code for
> the ARM recently which was preventing the prologue scanner from
> scanning far enough.  (Think about what happens when the optimizer
> moves a few of the instructions from the body of the function into the
> prologue -- with debugging info present.  The instruction(s) in
> question are tagged with some line numbers and the prologue scanner
> will stop too soon.)
> 
> If you really think that we need this bit of code, I'll need to
> examine it a lot more closely and run some of my own tests to
> make sure it doesn't cause a problem.  (The rest of the patch
> looks fine to me.)
> 
> Kevin

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de