From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id D1F5A3858D20 for ; Wed, 31 May 2023 06:41:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D1F5A3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 14BCA1F8CD; Wed, 31 May 2023 06:41:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1685515301; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2s7QkfSiFoNJh2850auCnbvsHTDFsW6/fFmsw4PS+iY=; b=mEVfkZypPbcxnCl/X78FspXQIjyznBTx5XNhyzPS51uQdI2SiN54th3GvlU8njsHUEQ26n cDPajo3nwTy6ZbX/R0RE1UlqETHI2xL9wdQmRQCKJ46Mw2J4MonsqdJrwcQ6oCJefpvFn0 WPmhZTX0EyriCGW9M+tPRPNisW4ktVc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1685515301; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2s7QkfSiFoNJh2850auCnbvsHTDFsW6/fFmsw4PS+iY=; b=nDEn65KI5LOldNTsiGwVh4jKqxQcAokGS/kC8nZStDLiqc9AcYii4fiEIzsLmss1auzfYM KVJRsMkaRF1XQxCQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id B3E752C141; Wed, 31 May 2023 06:41:40 +0000 (UTC) Date: Wed, 31 May 2023 06:41:40 +0000 (UTC) From: Richard Biener To: "juzhe.zhong@rivai.ai" cc: "richard.sandiford" , gcc-patches , linkw Subject: Re: Re: [PATCH] VECT: Change flow of decrement IV In-Reply-To: Message-ID: References: <20230530112824.297599-1-juzhe.zhong@rivai.ai>, , , <685EE879E20B3272+6338EB42-0A9D-4147-993D-99DC8FF7C832@rivai.ai>, , User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 31 May 2023, juzhe.zhong@rivai.ai wrote: > Hi?all. I have posted my several investigations: > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620101.html > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620105.html > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620108.html > > Turns out when "niters is a constant value and vf is a constant value" > This patch can allow SCEV/IVOPTS optimize a lot for RVV too (Take tesecase from IBM's testsuite for example) and I think this patch can fix IBM's cunroll issue. > Even though it will produce a 'mv' instruction in some ohter cases for RVV, I think Gain > Pain overal. > > Actually, for current flow: > > step = MIN () > ... > remain = remain - step. > > I don't know how difficult to extend SCEV/IVOPTS to fix this issue. > So, could you make a decision for this patch? > > I wonder whether we should apply the approach of this patch (the codes can be refined after well reviewed) or > we should extend SCEV/IVOPTS ? I don't think we can do anything in SCEV for this which means we'd need to special-case this in niter analysis, in IVOPTs and any other passes that might be affected (and not fixed by handling it in niter analysis). While improving niter analysis would be good (the user could write this pattern as well) I do not have time to try implementing that (I have no idea how ugly or robust it is going to be). So I think we should patch this up in the vectorizer itself like with your patch. I'm going to wait for Richards input though since he seems to disagree. Note with SELECT_VL all bets will be off since as I understand the value it gives can vary from iteration to iteration (but we know a lower and maybe an upper bound?) Thanks, Richard. > Thanks. > > > juzhe.zhong@rivai.ai > > From: ??? > Date: 2023-05-30 23:05 > To: rguenther > CC: richard.sandiford; gcc-patches; linkw > Subject: Re: Re: [PATCH] VECT: Change flow of decrement IV > More information of power's testcase: > > Before this patch: > test_npeel_int16_t: > lui a4,%hi(.LANCHOR0+130) > lui a3,%hi(.LANCHOR1) > addi a3,a3,%lo(.LANCHOR1) > addi a4,a4,%lo(.LANCHOR0+130) > li a5,58 > li a2,16 > vsetivli zero,16,e16,m1,ta,ma > vl1re16.v v3,0(a3) > vid.v v1 > .L5: > minu a3,a5,a2 > vsetvli zero,a3,e16,m1,ta,ma > sub a5,a5,a3 > vse16.v v1,0(a4) > vsetivli zero,16,e16,m1,ta,ma > addi a4,a4,32 > vadd.vv v1,v1,v3 > bne a5,zero,.L5 > ret > > After this patch: > test_npeel_int16_t: > lui a5,%hi(.LANCHOR0) > addi a5,a5,%lo(.LANCHOR0) > li a1,16 > vsetivli zero,16,e16,m1,ta,ma > addi a2,a5,130 > vid.v v1 > addi a3,a5,162 > vadd.vx v4,v1,a1 > addi a4,a5,194 > li a1,32 > vadd.vx v3,v1,a1 > vse16.v v1,0(a2) > vse16.v v4,0(a3) > vse16.v v3,0(a4) > addi a5,a5,226 > li a1,48 > vadd.vx v2,v1,a1 > vsetivli zero,10,e16,m1,ta,ma > vse16.v v2,0(a5) > ret > > It's obvious, previously, power's testcase in RVV side can not unroll, but after this patch, in RVV side, it can unroll now. > > > juzhe.zhong@rivai.ai > > From: Richard Biener > Date: 2023-05-30 20:33 > To: juzhe.zhong > CC: Richard Sandiford; gcc-patches; linkw > Subject: Re: [PATCH] VECT: Change flow of decrement IV > On Tue, 30 May 2023, juzhe.zhong wrote: > > > This patch will generate the number of rgroup ?mov? instructions inside the > > loop. This is unacceptable. For example?if number of rgroups=3? will be 3 more > > instruction in loop. If this patch is necessary? I think I should find a way > > to fix it. > > That's odd, you only need to adjust the IV which is used in the exit test, > not all the others. > > > ---- Replied Message ---- > > From > > Richard Sandiford > > Date > > 05/30/2023 19:41 > > To > > juzhe.zhong@rivai.ai > > Cc > > gcc-patches, > > rguenther, > > linkw > > Subject > > Re: [PATCH] VECT: Change flow of decrement IV > > "juzhe.zhong@rivai.ai" writes: > > > Before this patch: > > > foo: > > > ble a2,zero,.L5 > > > csrr a3,vlenb > > > srli a4,a3,2 > > > .L3: > > > minu a5,a2,a4 > > > vsetvli zero,a5,e32,m1,ta,ma > > > vle32.v v2,0(a1) > > > vle32.v v1,0(a0) > > > vsetvli t1,zero,e32,m1,ta,ma > > > vadd.vv v1,v1,v2 > > > vsetvli zero,a5,e32,m1,ta,ma > > > vse32.v v1,0(a0) > > > add a1,a1,a3 > > > add a0,a0,a3 > > > sub a2,a2,a5 > > > bne a2,zero,.L3 > > > .L5: > > > ret > > > > > > After this patch: > > > > > > foo: > > > ble a2,zero,.L5 > > > csrr a3,vlenb > > > srli a4,a3,2 > > > neg a7,a4 -->>>additional instruction > > > .L3: > > > minu a5,a2,a4 > > > vsetvli zero,a5,e32,m1,ta,ma > > > vle32.v v2,0(a1) > > > vle32.v v1,0(a0) > > > vsetvli t1,zero,e32,m1,ta,ma > > > mv a6,a2 -->>>additional instruction > > > vadd.vv v1,v1,v2 > > > vsetvli zero,a5,e32,m1,ta,ma > > > vse32.v v1,0(a0) > > > add a1,a1,a3 > > > add a0,a0,a3 > > > add a2,a2,a7 > > > bgtu a6,a4,.L3 > > > .L5: > > > ret > > > > > > There is 1 more instruction in preheader and 1 more instruction in loop. > > > But I think it's OK for RVV since we will definitely be using SELECT_VL so > > this issue will gone. > > > > But what about cases where you won't be using SELECT_VL, such as SLP? > > > > Richard > > > > > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)