public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
	    GCC Patches <gcc-patches@gcc.gnu.org>,
	    Segher Boessenkool <segher@kernel.crashing.org>,
	    Bill Schmidt <wschmidt@linux.ibm.com>,
	    "bin.cheng" <bin.cheng@linux.alibaba.com>,
	    Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PATCH v2 3/3] Consider doloop cmp use in ivopts
Date: Wed, 15 May 2019 08:47:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.20.1905151044210.10704@zhemvz.fhfr.qr> (raw)
In-Reply-To: <368b8ca4-dbae-b88c-23b3-dbae2bfd0dee@linux.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

On Wed, 15 May 2019, Kewen.Lin wrote:

> on 2019/5/14 下午3:26, Richard Biener wrote:
> > On Tue, May 14, 2019 at 5:10 AM <linkw@linux.ibm.com> wrote:
> >>
> >> From: Kewen Lin <linkw@linux.ibm.com>
> >>
> >> Previous version link for background:
> >> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
> >>
> >> Firstly, it's to call predict_doloop_p hook to check this
> >> loop will be transformed to doloop or not, if yes, find
> >> the expected comp iv use and its dependent original iv,
> >> set the iv candidate as bind_cand of the group.
> >> In following candidate selection process, we will bypass
> >> the group with bind_cand, since we don't want to affect
> >> global decision making for an iv use which will be
> >> eliminated eventually.  At the time of iv candidate set
> >> finalization, we will fill the cost pair for the group
> >> with bind_cand.  If the bind_cand is already in the final
> >> set, then just use it. Otherwise, we can check whether one
> >> of existing final set is better and fill with that if so.
> >>
> >> Bootstrapped and regression testing passed on powerpc64le.
> >>
> >> Is it ok for trunk?
> > 
> > I wonder what prevents IVOPTs to consider a counter IV
> > (eventually such candidate needs to be added if that's not
> > already done) to be the most profitable variant w/o any
> > of the other changes?  I guess that would be costing of
> > the IV adjust plus branch which we would need to lower
> > in case there's nothing inside the loop that would make
> > later doloop transform fail?
> > 
> > Richard.
> > 
> 
> If the question is for "w/o this patch", I think IVOPTs
> can find counter IV as the most profitable one for the cmp
> use in most time.  But the key issue is that it may stop
> us to bring in more iv cands.  We have to add on iv cost
> of new cand desirable for some iv use, it's probably more
> than the cost of just using counter IV for the interest
> use.  
> 
> If the question is for "w/i this patch", since we bypass
> the doloop cmp use in candidate determination algorithm, 
> it's possible that some other iv cands are preferred for 
> the remaining uses rather than the counter IV. For example,
> for some address type iv use, iv cand with memory based is
> mostly better.

Ah, so the key issue is that the doloop IV is "free"?  That
is, it doesn't consume a general register and whatnot?  That
is allocating this IV doesn't really interfere with other IVs?
But can other uses be based on the doloop IV easily (if the
IV doesn't reside in a general reg?)?

Otherwise I understand that IVOPTs doesn't properly cost
the doloop IV update and conditional branch.  That's clearly
something we should fix (maybe even indepenently on other
changes).  One important thing is that we need to base costs
on a common base to not compare apples and oranges, didn't
dig into your patch in detail enough to see whether it
fits into the general cost model or whether it is a hack
ontop of everything.

Richard.

  reply	other threads:[~2019-05-15  8:47 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14  3:10 linkw
2019-05-14  7:26 ` Richard Biener
2019-05-15  5:03   ` Kewen.Lin
2019-05-15  8:47     ` Richard Biener [this message]
2019-05-15 16:17       ` Segher Boessenkool
2019-05-16  7:25         ` Richard Biener
2019-05-16 17:35           ` Segher Boessenkool
2019-05-16  3:53       ` Kewen.Lin
2019-05-16 18:41       ` Jeff Law
2019-05-16 21:42         ` Segher Boessenkool
2019-06-19 11:47 ` [PATCH v3 3/3] PR80791 " Kewen.Lin
2019-06-20  9:09   ` Segher Boessenkool
2019-06-20 12:08     ` Kewen.Lin
2019-06-20 12:17       ` Kewen.Lin
2019-07-10  2:31         ` [PING^1][PATCH v4 " Kewen.Lin
2019-07-12 12:40           ` Richard Biener
2019-07-12 14:10             ` Segher Boessenkool
2019-07-15  6:40             ` Kewen.Lin
2019-07-15  6:50             ` Bin.Cheng
2019-07-21  9:06   ` [PATCH v3 " Bin.Cheng
2019-07-22  5:42     ` Kewen.Lin
2019-07-22  6:53       ` Segher Boessenkool
2019-07-22  7:18         ` Kewen.Lin
2019-07-22  8:02         ` Richard Biener
2019-07-22 21:47           ` Segher Boessenkool
2019-07-23  6:14             ` Kewen.Lin
2019-07-23  7:38             ` Richard Biener
2019-07-23  6:09           ` Kewen.Lin
2019-07-23  8:05             ` Richard Biener
2019-07-23  6:28       ` [PATCH v5 " Kewen.Lin
2019-08-14  7:48         ` [PATCH v6 " Kewen.Lin
2019-08-21 13:42           ` Bin.Cheng
2019-08-22  7:09             ` Kewen.Lin
2019-08-22  8:07               ` Bin.Cheng
2019-08-22  9:16                 ` Kewen.Lin
2019-08-23  5:31                   ` Bin.Cheng
2019-08-23  9:57                     ` Kewen.Lin
2019-08-23 10:43                       ` Bin.Cheng
2019-08-23 11:02                         ` Segher Boessenkool
2019-09-11  6:18                           ` Kewen.Lin
2019-09-12  8:14                             ` Richard Biener
2019-09-14  9:35                               ` Kewen.Lin
2019-08-24 22:43                         ` Kewen.Lin

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=alpine.LSU.2.20.1905151044210.10704@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=bin.cheng@linux.alibaba.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=linkw@linux.ibm.com \
    --cc=richard.guenther@gmail.com \
    --cc=segher@kernel.crashing.org \
    --cc=wschmidt@linux.ibm.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).