public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ghassan Shobaki <gshobaki@ece.ucdavis.edu>
To: Jan Hubicka <jh@suse.cz>
Cc: gcc-help@gcc.gnu.org, "Vladimir N. Makarov" <vmakarov@redhat.com>,
	gcc@gnu.org, hubicka@ucw.cz
Subject: Re: Superblock Instruction Scheduling in GCC 3.4
Date: Thu, 29 Jan 2004 10:14:00 -0000	[thread overview]
Message-ID: <Pine.GHP.4.58.0401282211460.5040@dante.ece.ucdavis.edu> (raw)
In-Reply-To: <20040128122317.GI8094@kam.mff.cuni.cz>


Ok, I have just verified that gcc DOES accept the -fsched2-use-tracer and
invoke the ebb scheduler as expected. However, it does not set the
flag_branch_probabilities automatically. It only sets it when I
explicitly use the -fbranch-probabilities command-line switch. Here are
the two cases that I have tried:

g++ -O3 -fsched2-use-traces
Generates ~151K superblocks on my benchmark suite with lots of large
superblocks that include 10 basic blocks or more

g++ -O3 -fsched2-use-traces -fbranch-probabilities
Generates only ~123K superblocks on my benchmark suite with the vast
majority of superblocks consisting of less than 10 basic blocks

So, the question is: Why did the compiler generate more superblocks
when branch probabilities were not computed? Do the superblocks generated
in that case make any sense?
And the bottom line question for me is: which setting should I use in my
research on superblocks?

Thanks

-Ghassan


On Wed, 28 Jan 2004, Jan Hubicka wrote:

> > Hi,
> >
> > I am currently experimenting with superblock scheduling in a prerelease
> > version (20040114) of gcc 3.4 on the spec2000 benchmarks. I have
> > a few questions:
> >
> > The version that I have does not seem to accept the
> > -fsched2-use-traces command line switch. So I went a head and set the
> > following global variables in toplev.c in order to enforce superblock
> > formation and scheduling:
> >
> > int flag_optimize = 1;
> > int flag_schedule_insns = 1;
> > int flag_schedule_insns_after_reload = 1;
> > int flag_sched2_use_traces = 1;
> >
> > Q1. Is there a known bug in version 3.4 related to command-line options?
> >     Or I am doing something wrong?
>
> I jus ttested and -fsched2-use-traces seems to just work for me.  What
> kind of problems do you get?
> >
> > Q2. Should I set the following flag as well?
> > int flag_branch_probabilities = ?;
> > I tried it both ways and the superblocks generated when this flag is
> > RESET are on average larger and have more branches in them (they are much
> > harder to schedule), which does not make sense to me. What is superblock
> > formation based on when branch probablities are not computed? It seems to
> > me that setting this flag should be necessary!
>
> Yes, however it should be implied by -O2 flag.
> You also may want the profile feedback.  Without -fbranch-probabilities
> you won't get any superblocks formed.
> >
> > Q3. Are there any other flags that I need to set in order to ensure
> > proper superblock formation?
>
> I think -O2 -fsched2-use-traces shall do what you want.
> >
> > Q3. I have looked into the trace formation code in tracer.c and was
> > confused about three different terms related to about the same
> > concept : probability, count and frequency. Is there a documention that
> > precisely defines each of these three terms and how they are used in
> > trace formation?
>
> You may take a look at cfg.texi documentation I sent to mailing list
> year or two ago, but it never went into official sources.
> In general the count represent number of execution of given edge/block
> when profile is read from feedback.  It is 64bit number.
> Each basic block has frequence that represent how commonly it is
> executed relative to REG_FREQ_BASE.  It is 32bit number and the most
> frequent basic block is known to have REG_FREQ_BASE frequency at the
> time profile was built, so it is easier to manipulate with when you
> don't care about exactness and it is also available without profile
> feedback based on guesses made by compiler.
> Probablity is set for edges and represent probability that control flow
> will leave basic block via that edge, again relative to REG_FREQ_BASE.
>
> Honza
> >
> > Thanks
> >
> > -Ghassan
>

  reply	other threads:[~2004-01-29  7:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-03  7:07 Superblock Instruction Scheduling in GCC Ghassan Shobaki
2003-12-03 14:05 ` Vladimir N. Makarov
2003-12-04  0:13   ` Jan Hubicka
2003-12-04  1:30     ` Ghassan Shobaki
2003-12-04 10:49       ` Jan Hubicka
2003-12-04 17:40         ` Vladimir Makarov
2003-12-09 21:45     ` Ghassan Shobaki
2004-01-28  3:26     ` Superblock Instruction Scheduling in GCC 3.4 Ghassan Shobaki
2004-01-28 12:51       ` Jan Hubicka
2004-01-29 10:14         ` Ghassan Shobaki [this message]
2004-01-29 11:15           ` Jan Hubicka
2004-02-01 18:19             ` Ghassan Shobaki
2004-02-01 21:56               ` Jan Hubicka
2004-02-02  5:54                 ` Ghassan Shobaki
2004-02-10 18:58                 ` Superblock Scheduling Alg in GCC Ghassan Shobaki
2004-02-10 20:10                   ` Vladimir Makarov
2004-02-10 20:18                     ` Vladimir Makarov
2004-02-10 20:28                       ` Jan Hubicka
2004-04-14 17:40                         ` Ghassan Shobaki
2004-04-15  8:44                           ` Vladimir Makarov
2004-05-27 14:12                         ` Ghassan Shobaki
2004-01-28 13:57 Superblock Instruction Scheduling in GCC 3.4 S. Bosscher

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=Pine.GHP.4.58.0401282211460.5040@dante.ece.ucdavis.edu \
    --to=gshobaki@ece.ucdavis.edu \
    --cc=gcc-help@gcc.gnu.org \
    --cc=gcc@gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=jh@suse.cz \
    --cc=vmakarov@redhat.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).