From: Richard Guenther <richard.guenther@gmail.com>
To: Xinliang David Li <davidxl@google.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: IVOPT improvement patch
Date: Tue, 11 May 2010 08:34:00 -0000 [thread overview]
Message-ID: <AANLkTiluCGvOYgihb0XJTtsk0VrVdY61PsEuoFgFz05w@mail.gmail.com> (raw)
In-Reply-To: <AANLkTini_oBL-mdWrt2IrVYw6f0-Mil_hi0AxPmqHjHv@mail.gmail.com>
On Tue, May 11, 2010 at 8:35 AM, Xinliang David Li <davidxl@google.com> wrote:
> Hi, IVOPT has been one of the main area of complaints from gcc users
> and it is often shutdown or user is forced to use inline assembly to
> write key kernel loops. The following (resulting from the
> investigation of many user complaints) summarize some of the key
> problems:
>
> 1) Too many induction variables are used and advanced addressing mode
> is not fully taken advantage of. On latest Intel CPU, the increased
> loop size (due to iv updates) can have very large negative impact on
> performance, e.g, when LSD and uop macro fusion get blocked. The root
> cause of the problem is not at the cost model used in IVOPT, but in
> the algorithm in finding the 'optimal' assignment from iv candidates
> to uses.
>
> 2) Profile information is not used in cost estimation (e.g. computing
> cost of loop variants)
>
> 3) For replaced IV (original) that are only live out of the loop (i.e.
> there are no uses inside loop), the rewrite of the IV occurs inside
> the loop which usually results in code more expensive than the
> original iv update statement -- and it is very difficult for later
> phases to sink down the computation outside the loop (see PR31792).
> The right solution is to materialize/rewrite such ivs directly outside
> the loop (also to avoid introducing overlapping live ranges)
>
> 4) iv update statement sometimes block the forward
> propagation/combination of the memory ref operation (depending the
> before IV value) with the loop branch compare. Simple minded
> propagation will lead to overlapping live range and addition copy/move
> instruction to be generated.
>
> 5) In estimating the global cost (register pressure), the registers
> resulting from LIM of invariant expressions are not considered
>
> 6) IN MEM_REF creation, loop variant and invariants may be assigned to
> the same part -- which is essentially a re-association blocking LIM
>
> 7) Intrinsic calls that are essentially memory operations are not
> recognized as uses.
8) Replacement pointer induction variables do not inherit alias-information
pessimizing MEM_REF memory operations.
> The attached patch handles all the problems above except for 7.
>
>
> Bootstrapped and regression tested on linux/x86_64.
>
> The patch was not tuned for SPEC, but SPEC testing was done.
> Observable improvements : gcc 4.85%, vpr 1.53%, bzip2 2.36%, and eon
> 2.43% (Machine CPU: Intel Xeon E5345/2.33Ghz, m32mode).
Can you split the patch into pieces and check SPEC numbers also
for 64bit operation? I assume that maybe powerpc people want to
check the performance impact as well.
Thanks,
Richard.
> Ok for trunk?
>
> Thanks,
>
> David
>
next prev parent reply other threads:[~2010-05-11 8:34 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-11 6:35 Xinliang David Li
2010-05-11 7:18 ` Zdenek Dvorak
2010-05-11 17:29 ` Xinliang David Li
2010-05-25 0:17 ` Xinliang David Li
2010-05-25 10:46 ` Zdenek Dvorak
2010-05-25 17:39 ` Xinliang David Li
2010-05-25 18:25 ` Zdenek Dvorak
2010-05-25 23:30 ` Xinliang David Li
2010-05-26 2:35 ` Zdenek Dvorak
2010-05-26 3:17 ` Xinliang David Li
2010-05-27 1:31 ` Xinliang David Li
2010-05-27 9:12 ` Zdenek Dvorak
2010-05-27 17:33 ` Xinliang David Li
2010-05-28 9:14 ` Zdenek Dvorak
2010-05-28 23:51 ` Xinliang David Li
2010-05-29 16:57 ` Zdenek Dvorak
2010-05-29 19:51 ` Xinliang David Li
2010-05-29 20:18 ` Zdenek Dvorak
2010-05-30 0:22 ` Xinliang David Li
[not found] ` <20100604105451.GB5105@kam.mff.cuni.cz>
2010-07-21 7:27 ` Xinliang David Li
2010-07-26 16:33 ` Sebastian Pop
2010-07-26 16:43 ` Xinliang David Li
2010-07-27 20:04 ` Pat Haugen
2010-07-27 20:25 ` Xinliang David Li
2010-07-29 3:50 ` H.J. Lu
2010-07-29 5:57 ` H.J. Lu
2010-07-29 7:44 ` Xinliang David Li
2010-07-29 8:28 ` Zdenek Dvorak
2010-07-29 14:37 ` H.J. Lu
2010-07-29 15:27 ` H.J. Lu
2010-07-29 16:09 ` H.J. Lu
2010-07-29 16:17 ` Richard Guenther
2010-07-29 16:55 ` H.J. Lu
2010-07-30 1:04 ` Xinliang David Li
2010-07-30 2:06 ` H.J. Lu
2010-07-30 5:41 ` Xinliang David Li
2010-07-30 7:19 ` Jakub Jelinek
2010-07-30 16:45 ` Xinliang David Li
2010-07-30 15:56 ` H.J. Lu
2010-07-30 16:58 ` Xinliang David Li
2010-07-30 17:07 ` Xinliang David Li
2010-07-30 17:43 ` H.J. Lu
2010-07-30 18:10 ` Xinliang David Li
2010-07-30 18:57 ` H.J. Lu
2010-07-30 21:04 ` H.J. Lu
2010-07-30 21:13 ` Xinliang David Li
2010-08-02 21:23 ` Xinliang David Li
2010-08-09 8:44 ` Zdenek Dvorak
2010-08-09 23:07 ` Xinliang David Li
2010-08-10 2:37 ` Xinliang David Li
2010-08-10 13:13 ` Zdenek Dvorak
2010-08-10 13:35 ` H.J. Lu
2010-08-10 14:18 ` H.J. Lu
2010-08-10 16:31 ` Xinliang David Li
2010-08-10 16:38 ` H.J. Lu
2010-08-10 17:13 ` Xinliang David Li
2010-08-10 17:26 ` H.J. Lu
2010-08-10 17:42 ` Xinliang David Li
2010-08-11 0:45 ` Xinliang David Li
2010-07-30 17:01 ` Xinliang David Li
2010-07-29 16:11 ` H.J. Lu
2010-07-29 14:17 ` H.J. Lu
2010-07-29 17:00 ` Xinliang David Li
2010-07-29 17:10 ` H.J. Lu
2010-10-28 19:28 ` H.J. Lu
2011-04-27 13:23 ` H.J. Lu
2010-07-30 15:06 ` H.J. Lu
2010-07-30 16:50 ` Xinliang David Li
2010-07-30 18:28 ` Bernd Schmidt
2010-07-30 18:34 ` Xinliang David Li
2010-07-29 7:26 ` Xinliang David Li
2010-12-30 17:23 ` H.J. Lu
2010-05-25 18:10 ` Toon Moene
2010-05-27 9:28 ` Zdenek Dvorak
2010-05-27 17:51 ` Xinliang David Li
2010-05-27 22:48 ` Zdenek Dvorak
2010-05-27 23:41 ` Xinliang David Li
2010-05-28 9:57 ` Zdenek Dvorak
2010-06-01 23:13 ` Xinliang David Li
2010-06-02 20:57 ` Zdenek Dvorak
2010-06-03 5:39 ` Xinliang David Li
2010-06-05 9:01 ` Zdenek Dvorak
2010-06-05 22:37 ` Xinliang David Li
2010-05-11 7:26 ` Steven Bosscher
2010-05-11 17:23 ` Xinliang David Li
2010-05-11 8:34 ` Richard Guenther [this message]
2010-05-11 9:48 ` Jan Hubicka
2010-05-11 10:04 ` Steven Bosscher
2010-05-11 14:24 ` Peter Bergner
2010-05-11 17:28 ` Xinliang David Li
2010-05-12 8:55 ` Richard Guenther
2010-05-11 17:19 ` Toon Moene
2010-05-11 17:49 ` Xinliang David Li
2010-05-11 21:52 ` Toon Moene
2010-05-11 22:31 ` Xinliang David Li
2010-05-11 22:44 ` Toon Moene
2010-05-13 13:00 ` Toon Moene
2010-05-13 13:30 ` Toon Moene
2010-05-13 16:23 ` Xinliang David Li
2010-05-14 4:26 ` Xinliang David Li
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=AANLkTiluCGvOYgihb0XJTtsk0VrVdY61PsEuoFgFz05w@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=davidxl@google.com \
--cc=gcc-patches@gcc.gnu.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).