[llvm] r251904 - [X86] Generate .cfi_adjust_cfa_offset correctly when pushing arguments

[Kreitzer, David L via llvm-commits]

Another issue with r251904 that I missed during the code review is that having usePreciseUnwindInfo depend on hasDebugInfo() is undesirable. Having "g" affect the contents of the .eh_frame section has all the same problems of having "g" affect the generated code. For example, "g" would mask a bug in the !usePreciseUnwindInfo .eh_frame code.

So providing a non-precise .eh_frame feature really needs to be predicated on having the ability to simultaneously create a precise .debug_frame and non-precise .eh_frame. In the meantime, having usePreciseUnwindInfo unconditionally return true seems like a reasonable solution.

Just to give an idea of the potential size savings from a non-precise .eh_frame, I used 32-bit icc -O2 to build cpu2k with and without -fasynchronous-unwind-tables. icc generates a non-precise .eh_frame by default, and the added switch makes it precise. The total non-precise .eh_frame size is 40988 bytes. The total precise .eh_frame size is 1175420. That's a factor of almost 30. The outgoing parameter push optimization is a major contributing factor for making the precise information so large, so I would expect similar results for llvm when the parameter push optimization is enabled.

- Dave

-----Original Message-----
From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] 
Sent: Monday, November 09, 2015 9:39 AM
To: Kuperstein, Michael M
Cc: Reid Kleckner; llvm-commits; Frederic Riss; Smith, Kevin B; Kreitzer, David L
Subject: Re: [llvm] r251904 - [X86] Generate .cfi_adjust_cfa_offset correctly when pushing arguments

On 8 November 2015 at 03:22, Kuperstein, Michael M <michael.m.kuperstein at intel.com> wrote:
> Ok.
>
> Any ideas for an option name that won’t be confusing (w.r.t
> –fasynchronous-unwind-tables) ?

I have a small preference for just always being precise.

But if adding an option, what about -feh-only-unwind-tables?

Cheers,
Rafael