public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Daniel Berlin" <dberlin@dberlin.org>
To: "Richard Guenther" <richard.guenther@gmail.com>
Cc: "Robert Kennedy" <jimbob@google.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Fold more aggressively for trip counts
Date: Wed, 03 Jan 2007 15:14:00 -0000	[thread overview]
Message-ID: <4aca3dc20701030714r40398f9aof7ac3203aa513a79@mail.gmail.com> (raw)
In-Reply-To: <84fc9c000701030557y771149b5kb19643b0a50dd502@mail.gmail.com>

On 1/3/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> On 1/3/07, Robert Kennedy <jimbob@google.com> wrote:
> > Attached is a patch to do a little bit of extra work in analyzing trip
> > counts for loops. As a side benefit, some other phases will perhaps
> > get slightly better folding results.
> >
> > The motivation for this patch came from some experiments I did with
> > doing strength reduction and linear function test replacement rather
> > early in optimization, before, e.g., vectorization. At first, code
> > introduced by SR caused some failures by keeping loops from being
> > analyzed well, hence the genesis of this patch.
> >
> > Bootstrapped and tested on i686-pc-linux-gnu.
>
> The fold-const change is ok if you add a testcase.
> tree_simplify_using_condition_1
> is already complex, ugly and slow - we shouldn't add to that more.
> Can you provide
> a testcase and see where we create a comparison that makes this extra testing
> worthwhile?  Can you fix this place instead?
>

The main place that exposes this is the Operator Strength Reduction
pass, which is not yet committed or submitted.
These are mainly generated by the  exit test replacement it performs
Theoretically you could work around this by moving OSR much earlier
than where we have it now, and then some other pass would probably
simplify these (VRP is my guess), but doing so is not really feasible
(You don't want to run strength reduction too early, it makes things
harder to analyze. We currently have it right before ivopts, which is
somewhere that both Zdenek and i agree is the right place for such a
pass).

  reply	other threads:[~2007-01-03 15:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-03  2:40 Robert Kennedy
2007-01-03  2:50 ` Andrew Pinski
2007-01-03  8:49   ` Paolo Bonzini
2007-01-03 13:57 ` Richard Guenther
2007-01-03 15:14   ` Daniel Berlin [this message]
2007-01-04 19:35   ` Robert Kennedy
2007-01-04 19:46     ` Richard Guenther
2007-01-04 19:49       ` Robert Kennedy
2007-01-04 19:54         ` Richard Guenther
2007-01-04 19:58           ` Robert Kennedy
2007-01-04 22:59     ` Zdenek Dvorak
2007-01-05  1:18       ` Robert Kennedy
2007-01-05  7:46         ` Zdenek Dvorak
2007-01-05 19:08           ` Robert Kennedy
2007-01-10  0:05       ` Robert Kennedy

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=4aca3dc20701030714r40398f9aof7ac3203aa513a79@mail.gmail.com \
    --to=dberlin@dberlin.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jimbob@google.com \
    --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).