On Tue, Dec 11, 2012 at 1:49 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Mon, Dec 10, 2012 at 10:07 PM, Mike Stump <mikest...@comcast.net> wrote: >> On Dec 10, 2012, at 12:42 PM, Xinliang David Li <davi...@google.com> wrote: >>> I have not measured the CFI size impact -- but conceivably it should >>> be larger -- which is unfortunate. >> >> Code speed and size are preferable to optimizing dwarf size… :-) I'd let >> dwarf 5 fix it! > > Well, different to debug info, CFI data has to be in memory to make > unwinding work. > These days most Linux distributions enable asyncronous unwind tables so any > size savings due to shorter push/pop epilogue/prologue sequences has to be > offsetted by the increase in CFI data. I'm not sure there is really a > speed difference > between both variants (well, maybe due to better icache footprint of > the push/pop > variant).
Yes, for large applications, this can be crucial to performance. > > That said - I'd prefer to have more data on this before making the switch for > the generic model. What was your original motivation? Just "theory" or was > it a real case? 1) some of the very large internal apps I measured benefit from this change (in terms of performance) 2) both ICC and LLVM do the same. I have already committed the patch. I will find some time to collect more size data and post it later. thanks, David > > Thanks, > Richard.
