From: <tm_gccmail@kloo.net>
To: Steven Bosscher <stevenb@suse.de>
Cc: gcc@gcc.gnu.org
Subject: Re: Interesting paper from Perdue
Date: Tue, 21 Sep 2004 07:21:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.21.0409201620550.10945-100000@mail.kloo.net> (raw)
In-Reply-To: <7347164.1095676587061.SLOX.WebMail.wwwrun@extimap.suse.de>
On Mon, 20 Sep 2004, Steven Bosscher wrote:
> I don't know if anyone has ever seen/read/mentioned this paper
> before, I might have missed it. Otherwise, interesting reading:
> https://engineering.purdue.edu/ECE/Research/TR/2004pdfs/TR-ECE-04-01.pdf
>
> Gr.
> Steven
I'll digress and rant a bit; apologizes in advance.
This is just the tip of the iceberg, really. There are many other
instances where various optimizations are improved in isolation and
degrade performance because they don't consider the effects on the other
optimization passes.
For example, Some of the recent work on alias analysis really worries me
because I believe this will result in a medium-term net performance
decrease on many targets.
Consider:
1. Improved alias analysis allows better disambiguation of memory
references.
2. The current scheduler is overly aggressive about hoisting loads, and
is only restrained by the inadequacy of the current alias analysis.
When alias analysis is improved, the first scheduling pass will
greatly increase register pressure.
3. The register allocator inserts code suboptimially (in particular,
restores are too early) and lacks basic fatures such as live-range
splitting and rematerialization.
Therefore, it exhibits increasingly bad behavior as register pressure
increases.
I think the following will occur:
1. Targets with the first instruction scheduling pass enabled will exhibit
a net decrease in performance due to increased register pressure. This
will be exacerbated if the target has fewer registers (e.g. slightly
worse on IA64, much worse on PPC). The SH is unlikely to be affected
due to scheduler modifications already implemented.
1. Targets without the first scheduling pass enabled will exhibit a net
decrease in performance only if the register set is very small
(fewer than 16 registers). This includes the x86 and most embedded
processors such as the H8/300, M68HC11, 8051, etc.
As I see it, the register allocator and the instruction scheduler are
really the base of the foundations for GCC optimization.
We keep adding improvements which:
1. Allow more intermediate values to be kept in registers which increase
register pressure
2. Allow memory to be retained in registers longer, which increases
register pressure
3. Create larger basic blocks, which increases register pressure
4. Allow more loop unrolling, which increases register pressure
5. etc
...and the register allocator doesn't handle the increased register
pressure well, so the net result is very little improvement.
We really spend some time improving the foundation of GCC instead of
piling more and more optimizations on top of it.
Toshi
next prev parent reply other threads:[~2004-09-21 0:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-20 13:31 Steven Bosscher
2004-09-21 7:21 ` tm_gccmail [this message]
2004-09-21 17:59 ` Vladimir Makarov
2004-09-21 18:39 ` Daniel Berlin
2004-09-21 16:01 ` Vladimir Makarov
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.LNX.4.21.0409201620550.10945-100000@mail.kloo.net \
--to=tm_gccmail@kloo.net \
--cc=gcc@gcc.gnu.org \
--cc=stevenb@suse.de \
/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).