From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E47633858C5E; Wed, 24 Jan 2024 07:32:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E47633858C5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706081530; bh=rQYsGsyEJnZ+uwtkjIJMnSzo/FPPNyoN5ecV347AUQs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RQt8Z3fggu2gh1DqVCnGq4OJ4PlQDHwfCmB6KX1ylJNQTk/X/IHCbgnv5MCLIQjmA RCrhTuZd3+2OqfkJcMQwblsikfPaxsR8kNSYJYQoh34bfApw2xwCE2u5GFd4W71A+T 9IxLAUaTA2AIGBXYMX/1JZVVQr/VRFK5/8WoTgzI= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled Date: Wed, 24 Jan 2024 07:32:10 +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: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113467 --- Comment #21 from Richard Biener --- (In reply to Tamar Christina from comment #20) > (In reply to rguenther@suse.de from comment #19) > > > Am 23.01.2024 um 18:06 schrieb tnfchris at gcc dot gnu.org : > > >=20 > > > =EF=BB=BFhttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113467 > > >=20 > > > --- Comment #18 from Tamar Christina --- > > > (In reply to Richard Biener from comment #7) > > >> I do wonder whether LOOP_VINFO_EARLY_BREAKS_VECT_PEELED actually wor= ks (since > > >> without early exits we cannot handle a non-empty latch because of co= rrectness > > >> issues). I'd very much have preferred to deal with these by loop ro= tation > > >> (there's the loop_ch pass). We're still doing this, even when > > >> LOOP_VINFO_EARLY_BREAKS_VECT_PEELED: > > >>=20 > > >> /* We assume that the loop exit condition is at the end of the loop= . i.e, > > >> that the loop is represented as a do-while (with a proper if-gua= rd > > >> before the loop if needed), where the loop header contains all t= he > > >> executable statements, and the latch is empty. */ > > >> if (!empty_block_p (loop->latch) > > >> || !gimple_seq_empty_p (phi_nodes (loop->latch))) > > >> return opt_result::failure_at (vect_location, > > >> "not vectorized: latch block not > > >> empty.\n"); > > >>=20 > > >> so that's a bit odd (but loop_ch tries to ensure the latch is empty = anyway). > > >>=20 > > >> Does the following fix the issue? > > >=20 > > > Not really sure I understand what the latch being empty has to do with > > > LOOP_VINFO_EARLY_BREAKS_VECT_PEELED as the latch is still empty even = with it. > >=20 > > The latch is everything after the IV exit. >=20 > Wait, are you saying, that conceptually if we pick an earlier exit as the > main exit then for the vectorizer the "latch" is everything below the fall > through edge? >=20 > i.e. that the "latch" then contains the normal loop exit? Yes. The reason the latch has (had) to be empty is that if there's any side-effects in it we wouldn't treat them correctly for the last vector iteration, since we'd prematurely exit the loop for it. So I wondered if the support for "peeled" early exits really would have made this restriction obsolete iff it were not restricted to multi-exit loops and iff the solution is that "easy" why we didn't chose to implement this before - so a way (at least for debugging) to disable the "peeled" case (which I think is also worse for performance than rotating the loop) would be nice. That said, for GCC 15 it would be nice to try to generalize this support to single-exit loops and relax the empty latch restriction.=