From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 192663858C62; Wed, 27 Dec 2023 15:21:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 192663858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1703690508; bh=AA7Q9wXMkf5RylhaPt0wpbNNnvsioeHfv5n3mAorHWI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=e9syraqp7KnPtrgrcAUJPXsHT2mboZgdl0vAWRIbLVq9DK39n0omrwU8lUHIQpZ8c 8dzvcCnVjK6JBC16W9pktQC7vD9SB3ArtzuTyY+VJ91afvkjMVbxljo2P/GZZOCBAK sz1zV5pRbo63hX3nXcHQjTnCTJ6wp6MVzrmB0dS4= From: "tnfchris at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/113134] gcc does not version loops with side-effect early breaks Date: Wed, 27 Dec 2023 15:21:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: tnfchris at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_reconfirmed_on short_desc everconfirmed bug_status 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=3D113134 Tamar Christina changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed|2023-12-25 00:00:00 |2023-12-27 Summary|Middle end early break |gcc does not version loops |vectorization: Fail to |with side-effect early |vectorize a simple early |breaks |break code | Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Tamar Christina --- So GCC's approach is much different than clang. I think this should be handled by IVcannon as it makes the vectorizer code = much easier. At the moment the vectorizer assumes that any exit it sees are actually needed. So even if I relax my patch to allow this we still produc= e a pointless compare. Looking at IVcannon it does for a constant sized array: Loop 1 iterates 1001 times. Loop 1 iterates at most 999 times. Loop 1 likely iterates at most 999 times. Analyzing # of iterations of loop 1 exit condition [0, + , 1](no_overflow) <=3D 1000 bounds on difference of bases: 1000 ... 1000 result: # of iterations 1001, bounded by 1001 Removed pointless exit: if (i_13 > 1000) but for the example attached: Loop 1 iterates 1001 times. Loop 1 iterates at most 1001 times. Loop 1 likely iterates at most 1001 times. Analyzing # of iterations of loop 1 exit condition [1, + , 1](no_overflow) < N_13(D) bounds on difference of bases: 0 ... 2147483646 It has correctly determined that the loop bounds is at most 1001 but since N can be < 1001 it doesn't think the additional exit is useless. However like clang we can just version the loop. Unlike clang however we can probably do better. if N >=3D 1000 then we can enter the vector code without the additional exi= t, but if N < 1000 we can use my new pass. It's not hard to allow this through the pass, but I doubt this will be acce= pted in stage3.. For best result the loop should be versioned like clang does. Richi?=