public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: RFA: Avoiding unprofitable speculation
Date: Wed, 17 Aug 2011 22:50:00 -0000	[thread overview]
Message-ID: <4E4C15BF.10403@redhat.com> (raw)
In-Reply-To: <CAFiYyc3OOBwkEUDC8F9OcbWmrYFgMoC-DbwuphgyD7110-jm_A@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/17/11 01:21, Richard Guenther wrote:

> 
> We don't have a way to distinguish branch-taken vs. branch-not-take 
> costs, right?
Not that I'm aware of.  However, BRANCH_COST does allow the backend to
change the cost of a branch based on its predictability.


> I would expect that for non-pipelined archs the branch does have the
> same cost all the time, so ifcvt would be correct, no?
The branch we're able to eliminate is typically (always?) an
unconditional branch.  The unconditional branch we eliminate is only
executed some percentage of the time based on the conditional branch
that remains in the stream.

So regardless of the underlying cost of the branch we eliminate, we
still want to compare the cost of the speculated insns against the
scaled cost of the branch we're able to eliminate.



> Do you happen to know how valgrind counts branches here?
I don't know all the low level details -- I'd have to sit down with the
annotation code in the cachegrind plugin.  Presumably since valgrind
also attempts to model branch prediction it carries a number of counters
associated with each branch which get bumped as needed by the
instrumented code.

Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOTBW/AAoJEBRtltQi2kC70kIH/183zcbFr5NiHbM7JO9xkGoL
lxiwEKsWW3m5x/PYRb+S82prPjRI/2ZzcnDE+ZzjffF+W2agOCdE29DvFjm8JkdI
bUwAMPUrxip5y9iZSwreywtbm73yw/9GTkkr+oHYZupqTUbbC3rw3kV5f/DJq/xP
jmzFPeK1U1Glmus9mWruiSwRloyh2o5usysdnB7aRhO/KdH1jWG7EfZ7cvfQhSWf
u8IYkxRsdQD/xd+6TpxOgmRj8kjJlYw0oAMjNsGkiNnNqyqzZBjOe6sHE59IWc27
Z35HrpRvXevuImE6XQF6KmBWiK1cjExVdmlnZMTuOdy/tXklmp0zLP1EAbP5Sd8=
=o4mr
-----END PGP SIGNATURE-----

  reply	other threads:[~2011-08-17 19:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-16 22:00 Jeff Law
2011-08-17  9:34 ` Richard Guenther
2011-08-17 22:50   ` Jeff Law [this message]
2011-08-18 22:59   ` Richard Henderson
2011-08-19 16:49     ` Jeff Law
2011-09-27  0:11     ` Jeff Law
2011-09-27 13:51       ` Richard Guenther

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=4E4C15BF.10403@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@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).