[llvm] r249522 - [X86] Emit .cfi_escape GNU_ARGS_SIZE when adjusting the stack before calls

Smith, Kevin B via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 12 13:49:26 PDT 2015


Just for clarification, I have always believed that -Os was about decreasing code size, not object module size.  Extra .cfi directives
have no impact whatsoever on code-size, only on object module size.

So, I think any -Os decisions should be about actual text section size, not about debug or EH unwinding info size.

Kevin Smith 

-----Original Message-----
From: llvm-commits [mailto:llvm-commits-bounces at lists.llvm.org] On Behalf Of Kuperstein, Michael M via llvm-commits
Sent: Monday, October 12, 2015 2:04 AM
To: Joerg Sonnenberger; friss at apple.com
Cc: llvm-commits at lists.llvm.org
Subject: RE: [llvm] r249522 - [X86] Emit .cfi_escape GNU_ARGS_SIZE when adjusting the stack before calls

Ah, I thought that on Darwin both debug and EH unwind data will not be able to encode the required CFI directives.
Assuming I was wrong, and this is only an issue for EH, we can fall back to "Force FP when EH is enabled, and use CFI for debugging (when we have no FP) " and get the same results.

(I'm sorry if I'm assuming a lot of nonsense :-) )

Michael
 
-----Original Message-----
From: llvm-commits [mailto:llvm-commits-bounces at lists.llvm.org] On Behalf Of Joerg Sonnenberger via llvm-commits
Sent: Monday, October 12, 2015 11:36
To: llvm-commits at lists.llvm.org
Subject: Re: [llvm] r249522 - [X86] Emit .cfi_escape GNU_ARGS_SIZE when adjusting the stack before calls

On Mon, Oct 12, 2015 at 03:22:20AM +0000, Kuperstein, Michael M wrote:
> I'm not sure whether forcing FP is by itself helpful for size or not. 
> On the one hand, we lose a register, potentially adding more spill code.
> On the other hand, ebp-relative addresses encode 1 byte smaller than 
> esp-relative addresses. So, it really depends on the workload.

Correct.

> 
> The question isn't whether -fno-omit-frame-pointer on its own helps 
> size, it's whether it hurts code size. If not, then it may be the 
> cheapest solution to the problem: turning off push optimization when 
> EH is enabled would definitely hurt code size, and so would adding 
> lots of CFI directives.

Many -Os users don't care about CFI directives and often disabling unwind data anyway. OSX is kind of the odd man out here.

> Also, this is the only solution I see (except turning push 
> optimization off completely, since we can't turn it off based on -g) 
> that would result in debuggable -Os executables on Darwin.

I don't think it is debugging you have to worry about, but correctness of unwind data? Debug frames don't use compact encoding?

Joerg
_______________________________________________
llvm-commits mailing list
llvm-commits at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
llvm-commits mailing list
llvm-commits at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits


More information about the llvm-commits mailing list