public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
	Ramana Radhakrishnan <ramana.gcc@googlemail.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] rs6000 branch probability changes
Date: Sat, 01 Jul 2017 13:34:00 -0000	[thread overview]
Message-ID: <20170701133441.GB6089@kam.mff.cuni.cz> (raw)
In-Reply-To: <CAGWvny=EvxWWxqTS6rVsSPZruwb_+PtxQLDy8Bp_0zRL-e-hkg@mail.gmail.com>

> Does the computed value of very_unlikely need to change for the new
> scale?  Can the profile machinery provide a helper function or macro
> instead of the current calculation replicated in many ports?

And to answer your first question, there is REG_BR_PROB_BASE scale which is not
chnaged by my patch and there is also internal scale for profile_probability
(which is completely captured by the type) which currently is also set to
10000 to let me compare profiles produced before and after the conversion.
I plan to set it to more sane value soon after I am reasonably sure that there
is nothing wrong and we don't have code quality regressions related to the
revamp.

General plan is:
  1) fix issues with updating and add verifier that when profile is available
     all probabilities and counts are initialized
  2) eliminate REG_BR_PROB_BASE uses where it is not necessary (we use it for
     various internal scaling purposes, i.e. when verioning loops)
  3) work on removing frequencies (in favour of counts) for callgraph.
     Because counts have quality now, it is easy to declare that given count
     was determined by static profile estimation and is function local.
  4) remove frequencies from CFG
  5) remove edge counts from CFG and keep only probabilities.  For this
     probabilities will need to get more precise (by increasing the scale)
  6) work on elimination of REG_BR_PROB_BASE representation from RTL
   

Honza

      parent reply	other threads:[~2017-07-01 13:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-30 13:36 David Edelsohn
2017-06-30 21:36 ` Ramana Radhakrishnan
2017-06-30 23:18   ` Segher Boessenkool
2017-07-01 12:59     ` David Edelsohn
2017-07-01 13:06       ` Jan Hubicka
2017-07-01 13:19         ` David Edelsohn
2017-07-01 13:23           ` Jan Hubicka
2017-07-01 13:34           ` Jan Hubicka [this message]

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=20170701133441.GB6089@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ramana.gcc@googlemail.com \
    --cc=segher@kernel.crashing.org \
    /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).