This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs


On Tue, Dec 11, 2012 at 1:49 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Mon, Dec 10, 2012 at 10:07 PM, Mike Stump <mikestump@comcast.net> wrote:
>> On Dec 10, 2012, at 12:42 PM, Xinliang David Li <davidxl@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]