public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: GCC Patches <gcc-patches@gcc.gnu.org>,
	"d.khalikov@partner.samsung.com"	<d.khalikov@partner.samsung.com>,
	"v.barinov@samsung.com"	<v.barinov@samsung.com>
Cc: nd <nd@arm.com>
Subject: Re: [PATCH] Frame pointer for arm with THUMB2 mode
Date: Tue, 28 Aug 2018 00:48:00 -0000	[thread overview]
Message-ID: <DB5PR08MB10308E8200EDA386225AA742830B0@DB5PR08MB1030.eurprd08.prod.outlook.com> (raw)

Hi,

> But we still have an issue with performance, when we are using default
> unwinder, which uses unwind tables. It could be up to 10 times faster to 
> use frame based stack unwinder instead "default unwinder".

Switching on the frame pointer typically costs 1-2% performance, so it's a bad
idea to use it. However changing the frame pointer like in the proposed patch
will have a much larger cost - both in performance and codesize. You'd be 
lucky if it is less than 10%. This is due to placing the frame pointer at the top
rather than the bottom of the frame, and that is very inefficient in Thumb-2.

You would need to unwind ~100k times a second before you might see a 
performance gain. However you pay the performance cost all the time, even
when no unwinding is required. So I don't see this as being a good idea.

If unwind performance is an issue, it would make far more sense to solve that.
Profiling typically hits the same functions again and again. Callgraph profiling to
a fixed depth hits the same functions all the time. So caching is the obvious
solution.

Doing real unwinding is also far more accurate than frame pointer based
unwinding (the latter doesn't handle leaf functions correctly, entry/exit in
non-leaf functions and shrinkwrapped functions - and this breaks callgraph
profiling).

So my question is, is there any point in making code run significantly slower
all the time and in return get inaccurate unwinding?

Cheers,
Wilco

             reply	other threads:[~2018-08-28  0:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180828004814epcas5p3fbd3af8edd93da263b6780ab3be11fe4@epcas5p3.samsung.com>
2018-08-28  0:48 ` Wilco Dijkstra [this message]
2018-08-28 10:44   ` Denis Khalikov
2018-09-05 12:11     ` Wilco Dijkstra
2018-09-05 13:53       ` Denis Khalikov
2018-09-05 13:56       ` Denis Khalikov
2018-09-05 14:11         ` Richard Earnshaw (lists)
2018-09-05 15:32         ` Wilco Dijkstra
2018-09-05 16:43           ` Denis Khalikov
2018-09-05 16:52             ` Richard Earnshaw (lists)
2018-09-05 17:01               ` Denis Khalikov
     [not found] <CGME20180827093530eucas1p2c931fb7d5bc0a73d2b657116b0288e1b@eucas1p2.samsung.com>
2018-08-27  9:35 ` Denis Khalikov

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=DB5PR08MB10308E8200EDA386225AA742830B0@DB5PR08MB1030.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=d.khalikov@partner.samsung.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nd@arm.com \
    --cc=v.barinov@samsung.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).