From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118671 invoked by alias); 19 Sep 2016 16:03:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 118655 invoked by uid 89); 19 Sep 2016 16:03:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=grouped_load, group_gap_adj, nunits, sk:GROUP_F X-HELO: BLU004-OMC2S35.hotmail.com Received: from blu004-omc2s35.hotmail.com (HELO BLU004-OMC2S35.hotmail.com) (65.55.111.110) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Sep 2016 16:03:33 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com ([65.55.111.72]) by BLU004-OMC2S35.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 19 Sep 2016 09:03:32 -0700 Received: from VE1EUR02FT058.eop-EUR02.prod.protection.outlook.com (10.152.12.52) by VE1EUR02HT031.eop-EUR02.prod.protection.outlook.com (10.152.13.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.619.6; Mon, 19 Sep 2016 16:03:29 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.12.52) by VE1EUR02FT058.mail.protection.outlook.com (10.152.13.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Mon, 19 Sep 2016 16:03:29 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) by AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) with mapi id 15.01.0629.006; Mon, 19 Sep 2016 16:03:29 +0000 From: Bernd Edlinger To: Richard Biener CC: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] Fix PR tree-optimization/77550 Date: Mon, 19 Sep 2016 16:20:00 -0000 Message-ID: References: In-Reply-To: authentication-results: spf=softfail (sender IP is 10.152.12.52) smtp.mailfrom=hotmail.de; suse.de; dkim=none (message not signed) header.d=none;suse.de; dmarc=none action=none header.from=hotmail.de; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.de discourages use of 10.152.12.52 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1;VE1EUR02HT031;6:0CD7Pex0USi3ZzeXYzMVofgtWe/WmYuJmysmemRNwZ0LrH2mNr12EUH/4Itd1h1e62UEfxlAHO5dihEHyGKDm4yPei53QXdCqo4l7wAhipVMZ6K03Hm8Lf/lXBmWU6rtq+l2wlsXXFhwRy5zN5l8JvwVbfmFez73rL6hm9xEpT16gjbxwb1rBpMyNCFdPS12pzZuQYWzPiFLuMF5cqgTI5b9D6YwOvsyIs7gtk/dBXiAiGBzlVBoxmTBDnTQvEzb+/h1UvjOlicyb5xHuzfoK2v4rMZTGrlSw5BF2nyYYRo=;5:IoQLtbtDBgOa1X/No9kHzXJaFLD983SpapYcsfLMpDWYOii1o17vor5mH+sKON9hJi1riY+/50Nm6114xKASwS4f+tfY24A6ByN6cvjOAIhnoVe4ioe5WqAohm+PVlEwv03Y/BNEg93zjmXcY2y09Q==;24:C/6hZOjUfL2sS5yQelhsiK9FY0Hlol/bMvHl+f8YngJn7xAkShYAuTT1OQTD5tKb+p9WyBa6+bt9Dvh8F7Wu2dkezx+L+2lMyoS3iyztOFA=;7:p42KQ9c8h4CpSSF8RK6odn2jUfSiuUpviSGpKV3gorWHN1JR3XBudqFHTRGm2qOUxRV4FpRIwo3Dk+w4cFrROXUGkqa54U82irFzBt1+Jee5pusYjSbIYcDurjA3aJmh51HIHSu3BqxmHbr79uOL3Iv7kJSRMc2fRgLqW2uVL73ArIZz309R5Zye5Jk3+Zh+FtrmqHgwl+Vauoycfyi9bQwvycpZ3DycWVvHzAKvrmYzglDimsffpPpOhbZ4Umn3Ime3KgBrlkKZmY5sR9ySgrkx/YmK7+LCBlOfl1uk9Z70wyIBXdlAXfj7rUeTLQLY x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:VE1EUR02HT031;H:AM4PR0701MB2162.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; x-ms-office365-filtering-correlation-id: 01eb856a-7550-4262-9ec3-08d3e0a67eb0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(1601124038)(1603103081)(1601125047);SRVR:VE1EUR02HT031; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:VE1EUR02HT031;BCL:0;PCL:0;RULEID:;SRVR:VE1EUR02HT031; x-forefront-prvs: 0070A8666B spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <44F98A645FA31A48B5DD26B847D41B6C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2016 16:03:29.2836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT031 X-SW-Source: 2016-09/txt/msg01186.txt.bz2 On 09/19/16 11:25, Richard Biener wrote: > On Sun, 18 Sep 2016, Bernd Edlinger wrote: > >> Hi, >> >> this PR shows that in vectorizable_store and vectorizable_load >> as well, the vector access always uses the first dr as the alias >> type for the whole access. But that is not right, if they are >> different types, like in this example. >> >> So I tried to replace all reference_alias_ptr_type (DR_REF (first_dr)) >> by an alias type that is correct for all references in the whole >> access group. With this patch we fall back to ptr_type_node, which >> can alias anything, if the group consists of different alias sets. >> >> >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >> Is it OK for trunk and gcc-6-branch? > > +/* Function get_group_alias_ptr_type. > + > + Return the alias type for the group starting at FIRST_STMT > + containing GROUP_SIZE elements. */ > + > +static tree > +get_group_alias_ptr_type (gimple *first_stmt, int group_size) > +{ > + struct data_reference *first_dr, *next_dr; > + gimple *next_stmt; > + int i; > + > + first_dr =3D STMT_VINFO_DATA_REF (vinfo_for_stmt (first_stmt)); > + next_stmt =3D GROUP_NEXT_ELEMENT (vinfo_for_stmt (first_stmt)); > + for (i =3D 1; i < group_size && next_stmt; i++) > + { > > > there is no need to pass in group_size, it's enough to walk > GROUP_NEXT_ELEMENT until it becomes NULL. > > Ok with removing the redundant arg. > > Thanks, > Richard. > Hmmm, I'm afraid this needs one more iteration. I tried first to check if there are no stmts after the group_size and noticed there are cases when group_size is 0, for instance in gcc.dg/torture/pr36244.c. I think there is a bug in vectorizable_load, here: if (grouped_load) { first_stmt =3D GROUP_FIRST_ELEMENT (stmt_info); /* For SLP vectorization we directly vectorize a subchain without permutation. */ if (slp && ! SLP_TREE_LOAD_PERMUTATION (slp_node).exists ()) first_stmt =3D ; group_size =3D GROUP_SIZE (vinfo_for_stmt (first_stmt)); =3D 0, and even worse: group_gap_adj =3D vf * group_size - nunits * vec_num; =3D -4 ! apparently GROUP_SIZE is only valid on the GROUP_FIRST_ELEMENT, while it may be 0 on SLP_TREE_SCALAR_STMTS (slp_node)[0] moving the GROUP_SIZE up before first_stmt is overwritten results in no different code.... Bernd.