From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) by sourceware.org (Postfix) with ESMTPS id 828FE385E038 for ; Wed, 20 Dec 2023 10:23:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 828FE385E038 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 828FE385E038 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703067792; cv=none; b=U0yr8SaG5tS2lCc+PGKk66K4s9WnaRclPUefJiwzYkbmBNviEvDjwOdlNf4JMIuUW+fzduhtw2OqK4iBLt7SKc8G3Ddqxe+bWKyeT2AVJS3aYZLVYW+Wv9hviVnLu1FI1XaaHQCFbKNCd5mroneiTTzMDX5x3etSMmBFIe4sOFE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703067792; c=relaxed/simple; bh=0B0xH9YzC1SsnBaV2GKgC0j3RBAqPAgZiCyOtHvgb7w=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=TTlLbPXos3ZmUdmvGBRceL0jZPax/5zbAWc1PxhF8yDKbsXD8/X+pEQuCApD78Z6KpA1pKH3jsSD36TW/R64xc4A5hitsmEq3ZKOZ37tdsJstQDTr5owD0qFo+xHImm90nzU174no8m3pF016dOz+NDlKGswB8UMwslmSjDxF68= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.4.150] (unknown [10.168.4.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 233341FD82; Wed, 20 Dec 2023 10:23:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1703067789; 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=c+8VISozTU8PFuNU1UOorDlLuG/rKr3y0oKPaV+p6OI=; b=Cn3BC1/eu0C4q3NoTYyDJhwlzTrRYLWoe9BT53FHPmy6H3EqzEzswQvioPbssKlfCtVf2T 3ypA8nhv/J9iWa9RHxko+O7vDtEl6ulg6ZGwaUvj3LhQmRTpkZMimmPr0LOOlntbeGyty6 XNp3n+dROGY4aZOnBn8moz502ISRelU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1703067789; 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=c+8VISozTU8PFuNU1UOorDlLuG/rKr3y0oKPaV+p6OI=; b=BWLuqiMSyYblTbgBvnR2FOIIiqR04QHN3iv3jSPidXiUxks+YTY32KliJtNCSLgToEi/NO hYnY4C7K1C5fSbAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1703067789; 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=c+8VISozTU8PFuNU1UOorDlLuG/rKr3y0oKPaV+p6OI=; b=Cn3BC1/eu0C4q3NoTYyDJhwlzTrRYLWoe9BT53FHPmy6H3EqzEzswQvioPbssKlfCtVf2T 3ypA8nhv/J9iWa9RHxko+O7vDtEl6ulg6ZGwaUvj3LhQmRTpkZMimmPr0LOOlntbeGyty6 XNp3n+dROGY4aZOnBn8moz502ISRelU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1703067789; 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=c+8VISozTU8PFuNU1UOorDlLuG/rKr3y0oKPaV+p6OI=; b=BWLuqiMSyYblTbgBvnR2FOIIiqR04QHN3iv3jSPidXiUxks+YTY32KliJtNCSLgToEi/NO hYnY4C7K1C5fSbAw== Date: Wed, 20 Dec 2023 11:21:56 +0100 (CET) From: Richard Biener To: Thomas Schwinge cc: Andrew Stubbs , Julian Brown , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] tree-optimization/113073 - amend PR112736 fix In-Reply-To: <871qbh4300.fsf@euler.schwinge.homeip.net> Message-ID: <2798rq4n-6qq4-6804-p37s-6845p837s57r@fhfr.qr> References: <20231219123224.3D481385E459@sourceware.org> <871qbh4300.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Level: X-Spam-Level: X-Spamd-Result: default: False [-3.10 / 50.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,tree-vect-stmts.cc:url]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; BAYES_HAM(-3.00)[100.00%] Authentication-Results: smtp-out2.suse.de; none X-Spam-Score: -3.10 X-Spam-Status: No, score=-11.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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, 20 Dec 2023, Thomas Schwinge wrote: > Hi! > > On 2023-12-19T13:30:58+0100, Richard Biener wrote: > > The PR112736 testcase fails on RISC-V because the aligned exception > > uses the wrong check. The alignment support scheme can be > > dr_aligned even when the access isn't aligned to the vector size > > but some targets are happy with element alignment. The following > > fixes that. > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. > > I've noticed this to regresses GCN target as follows: > > PASS: gcc.dg/vect/bb-slp-pr78205.c (test for excess errors) > PASS: gcc.dg/vect/bb-slp-pr78205.c scan-tree-dump-times slp2 "optimized: basic block" 3 > PASS: gcc.dg/vect/bb-slp-pr78205.c scan-tree-dump-times slp2 "BB vectorization with gaps at the end of a load is not supported" 1 > [-PASS:-]{+FAIL:+} gcc.dg/vect/bb-slp-pr78205.c scan-tree-dump-times optimized " = c\\[4\\];" 1 > > As so often, I've got no clue whether that's a vectorizer, GCN back end, > or test case issue. ;-) > > 'diff'ing before vs. after: > > --- bb-slp-pr78205.c.191t.slp2 2023-12-20 09:49:45.834344620 +0100 > +++ bb-slp-pr78205.c.191t.slp2 2023-12-20 09:10:14.706300941 +0100 > [...] > @@ -505,8 +505,9 @@ > [...]/bb-slp-pr78205.c:9:8: note: create vector_type-pointer variable to type: vector(4) double vectorizing a pointer ref: c[0] > [...]/bb-slp-pr78205.c:9:8: note: created &c[0] > [...]/bb-slp-pr78205.c:9:8: note: add new stmt: vect__1.7_19 = MEM [(double *)&c]; > -[...]/bb-slp-pr78205.c:9:8: note: add new stmt: vect__1.8_20 = MEM [(double *)&c + 32B]; > -[...]/bb-slp-pr78205.c:9:8: note: add new stmt: vect__1.9_21 = VEC_PERM_EXPR ; > +[...]/bb-slp-pr78205.c:9:8: note: add new stmt: _20 = MEM[(double *)&c + 32B]; > +[...]/bb-slp-pr78205.c:9:8: note: add new stmt: vect__1.8_21 = {_20, 0.0, 0.0, 0.0}; > +[...]/bb-slp-pr78205.c:9:8: note: add new stmt: vect__1.9_22 = VEC_PERM_EXPR ; > [...]/bb-slp-pr78205.c:9:8: note: ------>vectorizing SLP node starting from: a[0] = _1; > [...]/bb-slp-pr78205.c:9:8: note: vect_is_simple_use: operand c[0], type of def: internal > [...]/bb-slp-pr78205.c:9:8: note: vect_is_simple_use: operand c[1], type of def: internal > [...] > @@ -537,9 +538,10 @@ > [...]/bb-slp-pr78205.c:13:8: note: transform load. ncopies = 1 > [...]/bb-slp-pr78205.c:13:8: note: create vector_type-pointer variable to type: vector(4) double vectorizing a pointer ref: c[2] > [...]/bb-slp-pr78205.c:13:8: note: created &c[2] > -[...]/bb-slp-pr78205.c:13:8: note: add new stmt: vect__3.14_23 = MEM [(double *)&c]; > -[...]/bb-slp-pr78205.c:13:8: note: add new stmt: vect__3.15_24 = MEM [(double *)&c + 32B]; > -[...]/bb-slp-pr78205.c:13:8: note: add new stmt: vect__1.16_25 = VEC_PERM_EXPR ; > +[...]/bb-slp-pr78205.c:13:8: note: add new stmt: vect__3.14_24 = MEM [(double *)&c]; > +[...]/bb-slp-pr78205.c:13:8: note: add new stmt: _25 = MEM[(double *)&c + 32B]; > +[...]/bb-slp-pr78205.c:13:8: note: add new stmt: vect__3.15_26 = {_25, 0.0, 0.0, 0.0}; > +[...]/bb-slp-pr78205.c:13:8: note: add new stmt: vect__1.16_27 = VEC_PERM_EXPR ; > [...]/bb-slp-pr78205.c:13:8: note: ------>vectorizing SLP node starting from: b[0] = _3; > [...]/bb-slp-pr78205.c:13:8: note: vect_is_simple_use: operand c[2], type of def: internal > [...]/bb-slp-pr78205.c:13:8: note: vect_is_simple_use: operand c[3], type of def: internal > [...] > @@ -580,18 +582,22 @@ > double _4; > double _5; > vector(2) double _17; > + double _20; > + double _25; > > [local count: 1073741824]: > vect__1.7_19 = MEM [(double *)&c]; > - vect__1.9_21 = VEC_PERM_EXPR ; > + _20 = MEM[(double *)&c + 32B]; > + vect__1.9_22 = VEC_PERM_EXPR ; > _1 = c[0]; > _2 = c[1]; > - MEM [(double *)&a] = vect__1.9_21; > - vect__3.14_23 = MEM [(double *)&c]; > - vect__1.16_25 = VEC_PERM_EXPR ; > + MEM [(double *)&a] = vect__1.9_22; > + vect__3.14_24 = MEM [(double *)&c]; > + _25 = MEM[(double *)&c + 32B]; that looks like a noop (but it's odd we keep the unused load) > + vect__1.16_27 = VEC_PERM_EXPR ; > _3 = c[2]; > _4 = c[3]; > - MEM [(double *)&b] = vect__1.16_25; > + MEM [(double *)&b] = vect__1.16_27; > _5 = c[4]; > _17 = {_5, _5}; > MEM [(double *)&x] = _17; > > --- bb-slp-pr78205.c.265t.optimized 2023-12-20 09:49:45.838344586 +0100 > +++ bb-slp-pr78205.c.265t.optimized 2023-12-20 09:10:14.706300941 +0100 > @@ -6,17 +6,17 @@ > vector(4) double vect__1.16; > vector(4) double vect__1.9; > vector(4) double vect__1.7; > - double _5; > vector(2) double _17; > + double _20; > > [local count: 1073741824]: > vect__1.7_19 = MEM [(double *)&c]; > - vect__1.9_21 = VEC_PERM_EXPR ; > - MEM [(double *)&a] = vect__1.9_21; > - vect__1.16_25 = VEC_PERM_EXPR ; > - MEM [(double *)&b] = vect__1.16_25; > - _5 = c[4]; > - _17 = {_5, _5}; > + _20 = MEM[(double *)&c + 32B]; that looks similar in the end, but trades c[4] for MEM here. That's because we CSEd c[4] with the "dead" load above. I think we could simply remove that extra scan-tree-dump-times, we should instead look to _not_ see a vector load starting at c[4], but scan-tree-dump-not is also not very reliable (in a false negative sense). I'll see what that "dead" load is. > + vect__1.9_22 = VEC_PERM_EXPR ; > + MEM [(double *)&a] = vect__1.9_22; > + vect__1.16_27 = VEC_PERM_EXPR ; > + MEM [(double *)&b] = vect__1.16_27; > + _17 = {_20, _20}; > MEM [(double *)&x] = _17; > return; > --- bb-slp-pr78205.s 2023-12-20 09:49:45.846344519 +0100 > +++ bb-slp-pr78205.s 2023-12-20 09:10:14.722300807 +0100 > @@ -41,7 +41,17 @@ > v_addc_co_u32 v7, s[22:23], 0, v7, s[22:23] > flat_load_dwordx2 v[6:7], v[6:7] offset:0 > s_waitcnt 0 > + v_writelane_b32 v8, s12, 0 > + v_writelane_b32 v9, s13, 0 > + s_mov_b64 exec, 1 > + v_add_co_u32 v8, vcc, 32, v8 > + v_addc_co_u32 v9, vcc, 0, v9, vcc > + flat_load_dwordx2 v[8:9], v[8:9] > + s_waitcnt 0 > + v_readlane_b32 s12, v8, 0 > + v_readlane_b32 s13, v9, 0 > s_mov_b64 s[18:19], 10 > + s_mov_b64 exec, 15 > v_cndmask_b32 v0, 0, 4, s[18:19] > s_mov_b64 exec, 15 > v_mov_b32 v11, v7 > @@ -73,15 +83,6 @@ > v_mov_b32 v5, s19 > v_addc_co_u32 v5, s[22:23], 0, v5, s[22:23] > flat_store_dwordx2 v[4:5], v[6:7] offset:0 > - v_writelane_b32 v4, s12, 0 > - v_writelane_b32 v5, s13, 0 > - s_mov_b64 exec, 1 > - v_add_co_u32 v4, vcc, 32, v4 > - v_addc_co_u32 v5, vcc, 0, v5, vcc > - flat_load_dwordx2 v[4:5], v[4:5] > - s_waitcnt 0 > - v_readlane_b32 s12, v4, 0 > - v_readlane_b32 s13, v5, 0 > s_mov_b64 exec, 3 > v_mov_b32 v6, s12 > v_mov_b32 v7, s13 > > I haven't looked at the full context, but this appears to effectively > just move this block of code, and use different registers. > > In: > > + s_mov_b64 exec, 15 > v_cndmask_b32 v0, 0, 4, s[18:19] > s_mov_b64 exec, 15 > > ... isn't the second (pre-existing) 's_mov_b64 exec, 15' now redundant, > though? I have no idea about that. > > Gr??e > Thomas > > > > PR tree-optimization/113073 > > * tree-vect-stmts.cc (vectorizable_load): Properly ensure > > to exempt only vector-size aligned overreads. > > --- > > gcc/tree-vect-stmts.cc | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc > > index fc6923cf68a..e9ff728dfd4 100644 > > --- a/gcc/tree-vect-stmts.cc > > +++ b/gcc/tree-vect-stmts.cc > > @@ -11476,7 +11476,9 @@ vectorizable_load (vec_info *vinfo, > > - (group_size * vf - gap), nunits)) > > /* DR will be unused. */ > > ltype = NULL_TREE; > > - else if (alignment_support_scheme == dr_aligned) > > + else if (known_ge (vect_align, > > + tree_to_poly_uint64 > > + (TYPE_SIZE_UNIT (vectype)))) > > /* Aligned access to excess elements is OK if > > at least one element is accessed in the > > scalar loop. */ > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra?e 201, 80634 M?nchen; Gesellschaft mit beschr?nkter Haftung; Gesch?ftsf?hrer: Thomas Heurung, Frank Th?rauf; Sitz der Gesellschaft: M?nchen; Registergericht M?nchen, HRB 106955 > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)