public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Bin.Cheng" <amker.cheng@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 24/33]New parameter bound on number of selected candidates
Date: Wed, 26 Apr 2017 14:13:00 -0000	[thread overview]
Message-ID: <CAHFci2_nmLOsfXje77ef-XM1f+W+4C2vd+X7xT6=OX2KJMdf6g@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc0HdZJb48LwqPm+=ZzGE-_fe+wc7wqumUYHMRr2zw_kGA@mail.gmail.com>

On Wed, Apr 26, 2017 at 2:22 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Tue, Apr 18, 2017 at 12:50 PM, Bin Cheng <Bin.Cheng@arm.com> wrote:
>> Hi,
>> IVOPTs still have difficulty for outer loop (especially for large loop nest), and tend to select too many candidates.
>> It's generally bad because of unavoidable register spilling.  In this case, we probably want to compute iv_uses with
>> small number of bivs.  Though this results in more computation inside of loop, it could improve spilling.
>> This patch adds new parameter bound on number of selected candidates, it simply gives up if too many candidates are
>> selected.  So far it works loop by loop, I am not sure if we want to by pass whole loop nest once this bound is hit.
>> Is it OK?
>
> Hmm, I don't like such kind of caps.  We should simply add less
> candidates in such cases?  Like cap this
> in find_optimal_iv_set instead, always using the original set of
> candidates just not trying harder?
>
> IIRC much of the problem is because the inner loop has been processed
> already and thus there may appear
> to be a very large number of "original" IVs already?  I may misremeber though.
Only loop header phis contribute to BIVs, IVs created by inner loop is
GIVs.  Yes, inner loop sometime creates too many non-linear type GIVs
for outer loop, which again causes too many candidates selected.  I
haven't found a good fix yet.  The coming register pressure estimate
should be helpful.   Note when register pressure is within range, we
do want inner loop to create as many GIVs for outer loop as possible.

>
> I think this patch doesn't really belong in the series?
Okay, I will create a standalone patch if necessary.

Thanks,
bin
>
> Richard.
>
>>
>> Thanks,
>> bin
>> 2017-04-11  Bin Cheng  <bin.cheng@arm.com>
>>
>>         * doc/invoke.texi (iv-max-selected-candidates): New.
>>         * params.def (PARAM_IV_MAX_SELECTED_CANDIDATES): New.
>>         * tree-ssa-loop-ivopts.c (MAX_SELECTED_CANDIDATES): New.
>>         (tree_ssa_iv_optimize_loop): Skip if too many cands are selected.

      reply	other threads:[~2017-04-26 13:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-18 10:51 Bin Cheng
2017-04-26 13:30 ` Richard Biener
2017-04-26 14:13   ` Bin.Cheng [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='CAHFci2_nmLOsfXje77ef-XM1f+W+4C2vd+X7xT6=OX2KJMdf6g@mail.gmail.com' \
    --to=amker.cheng@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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).