From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 72F4F385801C; Wed, 10 Aug 2022 05:25:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 72F4F385801C From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/106322] [12/13 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5 Date: Wed, 10 Aug 2022 05:25:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.1.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: linkw at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2022 05:25:29 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106322 --- Comment #37 from Kewen Lin --- (In reply to Andrew Pinski from comment #36) > You might need to do -O2 -fPIE -pie to reproduce the issue as debian is > configured with --enable-default-pie Thanks for the hint! I can reproduce this but it needs one more explicit cpu type like -mcpu=3Dpower4/5/6. The problem comes from slp1, so -fno-tree-slp-vectorize can make it pass. It seems to expose one latent issue, for the code in vect_recog_mulhs_patte= rn: vect_pattern_detected ("vect_recog_mulhs_pattern", last_stmt); /* Check for target support. */ tree new_vectype =3D get_vectype_for_scalar_type (vinfo, new_type); if (!new_vectype || !direct_internal_fn_supported_p (ifn, new_vectype, OPTIMIZE_FOR_SPEED)) return NULL; At this time, the new_vectype is=20 (gdb) pge new_vectype vector(2) short unsigned int the current target doesn't support umul_highpart optab for V2HImode at all,= but the check doesn't fail since in the function direct_optab_supported_p static bool direct_optab_supported_p (direct_optab optab, tree_pair types, optimization_type opt_type) { machine_mode mode =3D TYPE_MODE (types.first); gcc_checking_assert (mode =3D=3D TYPE_MODE (types.second)); return direct_optab_handler (optab, mode, opt_type) !=3D CODE_FOR_nothing; } (gdb) pge types.first vector(2) short unsigned int (gdb) p mode $12 =3D E_SImode the current target does support umul_highpart optab for SImode, so it doesn= 't fail. But we expected to query with vector mode for the given type, it's wr= ong in functionality to use scalar insn for vector operation here, so this resu= lt is unexpected.=