Do not disable -fomit-frame-pointer on !ACCUMULATE_OUTGOING_ARGS targets

Hi,

process_options has had these lines for a couple of releases:

  /* ??? Unwind info is not correct around the CFG unless either a frame
     pointer is present or A_O_A is set.  Fixing this requires rewriting
     unwind info generation to be aware of the CFG and propagating states
     around edges.  */
  if (flag_unwind_tables && !ACCUMULATE_OUTGOING_ARGS
      && flag_omit_frame_pointer)
    {
      warning (0, "unwind tables currently require a frame pointer "
	       "for correctness");
      flag_omit_frame_pointer = 0;
    }

I think that's too broad: for example, it's a common pattern for a target to 
really enable -fomit-frame-pointer only if the stack pointer is unchanging in 
the function; in this case, the unwind info will be correct even if !A_O_A.

So I'm proposing to disable -fomit-frame-pointer on a per-function basis 
instead in ira_setup_eliminable_regset.

Tested on x86_64-suse-linux, OK for the mainline?


2013-03-25  Eric Botcazou  <ebotcazou@adacore.com>

	* toplev.c (process_options): Do not disable -fomit-frame-pointer on a
	general basis if unwind info is requested and ACCUMULATE_OUTGOING_ARGS
	is not enabled.
	* ira.c (ira_setup_eliminable_regset): Instead disable it only on a per
	function basis if the stack pointer is not unchanging in the function.

On 03/25/2013 04:26 AM, Eric Botcazou wrote:
> process_options has had these lines for a couple of releases:
> 
>   /* ??? Unwind info is not correct around the CFG unless either a frame
>      pointer is present or A_O_A is set.  Fixing this requires rewriting
>      unwind info generation to be aware of the CFG and propagating states
>      around edges.  */

Heh.  We've actually fixed this now -- unwind info generation aware of
the cfg is exactly what pass_dwarf2_frame does.  So I guess this comment
has been out of date since gcc 4.7.


r~

> Heh.  We've actually fixed this now -- unwind info generation aware of
> the cfg is exactly what pass_dwarf2_frame does.  So I guess this comment
> has been out of date since gcc 4.7.

I see, thanks.  So what do you suggest doing at this point?  Entirely remove 
the block of code?  But AFAICS pass_dwarf2_frame isn't always enabled.  Apply 
the patch anyway with the appropriate additional conditions?

On 03/26/2013 03:29 PM, Eric Botcazou wrote:
>> Heh.  We've actually fixed this now -- unwind info generation aware of
>> the cfg is exactly what pass_dwarf2_frame does.  So I guess this comment
>> has been out of date since gcc 4.7.
> 
> I see, thanks.  So what do you suggest doing at this point?  Entirely remove 
> the block of code?  But AFAICS pass_dwarf2_frame isn't always enabled.  Apply 
> the patch anyway with the appropriate additional conditions?
> 

Isn't pass_dwarf2_frame enabled whenever we're generating any unwind info?


r~

> Isn't pass_dwarf2_frame enabled whenever we're generating any unwind info?

Essentially, yes:

static bool
gate_dwarf2_frame (void)
{
#ifndef HAVE_prologue
  /* Targets which still implement the prologue in assembler text
     cannot use the generic dwarf2 unwinding.  */
  return false;
#endif

  /* ??? What to do for UI_TARGET unwinding?  They might be able to benefit
     from the optimized shrink-wrapping annotations that we will compute.
     For now, only produce the CFI notes for dwarf2.  */
  return dwarf2out_do_frame ();
}