From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-519403-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 69430 invoked by alias); 12 Feb 2020 08:07:33 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 69419 invoked by uid 89); 12 Feb 2020 08:07:32 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=
X-HELO: mx2.suse.de
Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Feb 2020 08:07:31 +0000
Received: from relay2.suse.de (unknown [195.135.220.254])	by mx2.suse.de (Postfix) with ESMTP id C65B6ABF4;	Wed, 12 Feb 2020 08:07:28 +0000 (UTC)
Date: Wed, 12 Feb 2020 08:07:00 -0000
From: Richard Biener <rguenther@suse.de>
To: Segher Boessenkool <segher@kernel.crashing.org>
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
In-Reply-To: <20200211180049.GW22482@gate.crashing.org>
Message-ID: <nycvar.YFH.7.76.2002120906210.18835@zhemvz.fhfr.qr>
References: <ddd8c186-fc88-96df-b1c0-f99edec654f2@linux.ibm.com> <20200120123332.GV3191@gate.crashing.org> <52c8eecc-3383-81ad-70ce-27c149d7a103@linux.ibm.com> <20200210212910.GL22482@gate.crashing.org> <nycvar.YFH.7.76.2002110829340.18835@zhemvz.fhfr.qr> <20200211074859.GV22482@gate.crashing.org> <nycvar.YFH.7.76.2002110850570.18835@zhemvz.fhfr.qr> <1ac98132-734e-0ee3-5ea2-7ec256ee92d2@ispras.ru> <nycvar.YFH.7.76.2002111456590.18835@zhemvz.fhfr.qr> <20200211180049.GW22482@gate.crashing.org>
User-Agent: Alpine 2.21 (LSU 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-SW-Source: 2020-02/txt/msg00713.txt.bz2

On Tue, 11 Feb 2020, Segher Boessenkool wrote:

> 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.

True.  For x86 we tried but did not come up with a sensible estimate
(probably the x86 uarchs are way too complicated to understand).

Richard.