public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Richard Biener <rguenther@suse.de>
Cc: Roman Zhuykov <zhroma@ispras.ru>,
	"Kewen.Lin" <linkw@linux.ibm.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>,
	       Bill Schmidt <wschmidt@linux.ibm.com>,
	       "bin.cheng" <bin.cheng@linux.alibaba.com>
Subject: Re: [PATCH 0/4 GCC11] IVOPTs consider step cost for different forms when unrolling
Date: Tue, 11 Feb 2020 18:00:00 -0000	[thread overview]
Message-ID: <20200211180049.GW22482@gate.crashing.org> (raw)
In-Reply-To: <nycvar.YFH.7.76.2002111456590.18835@zhemvz.fhfr.qr>

On Tue, Feb 11, 2020 at 02:58:47PM +0100, Richard Biener wrote:
> On Tue, 11 Feb 2020, Roman Zhuykov wrote:
> > 11.02.2020 11:01, Richard Biener wrote:
> > Sound good, but IMHO modulo scheduler is not the best choice to be the
> > first step implementing such a concept.
> 
> True ;)   But since the context of this thread is unrolling ...
> Not sure how you'd figure the unroll factor to apply if you want
> to do unrolling within a classical scheduling framework?  Maybe
> unroll as much as you can fill slots until the last instruction
> of the first iteration retires?

That will be terrible on register-rich architectures: it *already* is
problematic how often some things are unrolled, blindly unrolling more
would make things worse.  We need to unroll more where it helps, but
less where it does not.  For that we need a good cost/benefit estimate.


Segher

  reply	other threads:[~2020-02-11 18:00 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  9:41 Kewen.Lin
2020-01-16  9:43 ` [PATCH 1/4 GCC11] Add middle-end unroll factor estimation Kewen.Lin
2020-01-20 13:12   ` Segher Boessenkool
2020-02-10  6:20     ` [PATCH 1/4 v2 " Kewen.Lin
2020-02-10 23:34       ` Segher Boessenkool
2020-02-11  6:51         ` [PATCH 1/4 v3 " Kewen.Lin
2020-02-11  7:00           ` Segher Boessenkool
2020-02-11  2:15       ` [PATCH 1/4 v2 " Jiufu Guo
2020-02-11  3:04         ` Kewen.Lin
2020-01-16 10:02 ` [PATCH 2/4 GCC11] Add target hook stride_dform_valid_p Kewen.Lin
2020-01-20 10:53   ` Richard Sandiford
2020-01-20 11:47     ` Richard Biener
2020-01-20 13:20     ` Segher Boessenkool
2020-02-25  9:46       ` Kewen.Lin
2020-03-02 11:09         ` Richard Sandiford
2020-03-03 12:26           ` Kewen.Lin
2020-05-13  5:50             ` Kewen.Lin
2020-05-28  2:17               ` Ping^1 [PATCH 2/4 V3] " Kewen.Lin
2020-05-28 10:54                 ` Richard Sandiford
2020-01-16 10:06 ` [PATCH 3/4 GCC11] IVOPTs Consider cost_step on different forms during unrolling Kewen.Lin
2020-02-25  9:48   ` [PATCH 3/4 V2 " Kewen.Lin
2020-05-13  5:42     ` [PATCH 3/4 V3 " Kewen.Lin
2020-01-16 10:12 ` [PATCH 4/4 GCC11] rs6000: P9 D-form test cases Kewen.Lin
2020-01-20 13:37   ` Segher Boessenkool
2020-02-10  6:25     ` [PATCH 4/4 v2 " Kewen.Lin
2020-02-10 23:51       ` Segher Boessenkool
2020-01-20 13:03 ` [PATCH 0/4 GCC11] IVOPTs consider step cost for different forms when unrolling Segher Boessenkool
2020-02-10  6:17   ` Kewen.Lin
2020-02-10 21:29     ` Segher Boessenkool
2020-02-11  2:56       ` Kewen.Lin
2020-02-11  7:34       ` Richard Biener
2020-02-11  7:49         ` Segher Boessenkool
2020-02-11  8:01           ` Richard Biener
2020-02-11 12:46             ` Roman Zhuykov
2020-02-11 13:58               ` Richard Biener
2020-02-11 18:00                 ` Segher Boessenkool [this message]
2020-02-12  8:07                   ` Richard Biener
2020-02-12 21:53                     ` Segher Boessenkool
2020-02-11 18:12               ` Segher Boessenkool
2020-02-12  8:13                 ` Richard Biener
2020-02-12 10:02                   ` Segher Boessenkool
2020-02-12 10:53                     ` Richard Biener
2020-02-12 22:05                       ` Segher Boessenkool
2020-02-13  7:48                         ` Richard Biener
2020-02-13  9:02                           ` Segher Boessenkool

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=20200211180049.GW22482@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=bin.cheng@linux.alibaba.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linkw@linux.ibm.com \
    --cc=rguenther@suse.de \
    --cc=wschmidt@linux.ibm.com \
    --cc=zhroma@ispras.ru \
    /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).