From: Richard Biener <richard.guenther@gmail.com>
To: Mike Stump <mikestump@comcast.net>
Cc: Xinliang David Li <davidxl@google.com>,
Uros Bizjak <ubizjak@gmail.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs
Date: Tue, 11 Dec 2012 09:49:00 -0000 [thread overview]
Message-ID: <CAFiYyc000_e9R4HDpjVUpJuooDbnk6NVH3BkUTU3jZRwEj=dpw@mail.gmail.com> (raw)
In-Reply-To: <2679866A-C8BE-4F73-B417-C0A8140D6E99@comcast.net>
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).
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?
Thanks,
Richard.
next prev parent reply other threads:[~2012-12-11 9:49 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-09 13:50 Uros Bizjak
2012-12-09 17:09 ` Дмитрий Дьяченко
2012-12-10 9:23 ` Richard Biener
2012-12-10 20:42 ` Xinliang David Li
2012-12-10 21:07 ` Mike Stump
2012-12-11 9:49 ` Richard Biener [this message]
2012-12-11 17:15 ` Xinliang David Li
-- strict thread matches above, loose matches on Subject: below --
2012-12-21 7:26 Xinliang David Li
2012-12-21 8:20 ` Zamyatin, Igor
2012-12-11 22:53 Xinliang David Li
2012-12-11 23:39 ` Xinliang David Li
2012-12-12 11:00 ` Richard Biener
2012-12-08 18:13 Xinliang David Li
2012-12-12 16:37 ` Jan Hubicka
2012-12-12 17:25 ` Xinliang David Li
2012-12-12 17:34 ` Xinliang David Li
2012-12-12 18:30 ` Jan Hubicka
2012-12-12 18:37 ` Andi Kleen
2012-12-12 18:43 ` Jan Hubicka
2012-12-12 18:43 ` Andi Kleen
2012-12-13 0:16 ` Xinliang David Li
2012-12-13 0:16 ` Xinliang David Li
2012-12-13 1:19 ` Jan Hubicka
2012-12-13 6:09 ` Xinliang David Li
2012-12-13 6:21 ` Jakub Jelinek
2012-12-13 7:05 ` Xinliang David Li
2012-12-13 19:28 ` Jan Hubicka
2012-12-13 10:22 ` Richard Biener
2012-12-13 19:43 ` H.J. Lu
2012-12-13 20:26 ` Jan Hubicka
2012-12-13 20:28 ` H.J. Lu
2012-12-13 20:40 ` Jan Hubicka
2012-12-13 21:02 ` H.J. Lu
2012-12-13 21:35 ` Jan Hubicka
2012-12-20 12:13 ` Melik-adamyan, Areg
2012-12-20 14:08 ` H.J. Lu
2012-12-20 15:05 ` Jan Hubicka
2012-12-20 15:07 ` Jan Hubicka
2012-12-20 15:22 ` H.J. Lu
2012-12-21 8:28 ` Zamyatin, Igor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFiYyc000_e9R4HDpjVUpJuooDbnk6NVH3BkUTU3jZRwEj=dpw@mail.gmail.com' \
--to=richard.guenther@gmail.com \
--cc=davidxl@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=mikestump@comcast.net \
--cc=ubizjak@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).