From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 37583385AF8A for ; Fri, 28 Jul 2023 13:24:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 37583385AF8A Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id AF1672829CA; Fri, 28 Jul 2023 15:24:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1690550655; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lxxwz7AtPQPwhKDa/pJ68qzjbLDT3IoqIV5prl/tMQU=; b=eddDEn4sBf3ZlkLBN6r5S4QLnjrqT3EpcuzoFgFWiYl2NemXPLkieGtpZK2aSLE0MAEh0N ZeP7FoG/tz3veRlEMgf63kQSr8uGdbzu+56GKCfHRbYBZQe1ZtmYnWLAsFLpZYGIDFQA8I 5Q1vpYVSik5fMihU2wvwgiSB4xqv4mY= Date: Fri, 28 Jul 2023 15:24:15 +0200 From: Jan Hubicka To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: Loop-split improvements, part 3 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,JMQ_SPF_NEUTRAL,KAM_NUMSUBJECT,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Fri, Jul 28, 2023 at 2:57 PM Jan Hubicka via Gcc-patches > wrote: > > > > Hi, > > This patch extends tree-ssa-loop-split to understand test of the form > > if (i==0) > > and > > if (i!=0) > > which triggers only during the first iteration. Naturally we should > > also be able to trigger last iteration or split into 3 cases if > > the test indeed can fire in the middle of the loop. > > > > Last iteration is bit trickier pattern matching so I want to do it > > incrementally, but I implemented easy case using value range that handled > > loops with constant iterations. > > > > The testcase gets misupdated profile, I will also fix that incrementally. > > > > Bootstrapped/regtested x86_64-linux, OK? > > OK, though I think we can handle more loops by simply conservatively peeling > one iteration at the beginning/end with such conditions and would be not subject > to all other limitations the loop splitting pass has? I was also thinking of extending loop peeling heuristics by this. Loop-ch already can handle case where the static test exits loop, so we could get this if I figure out how to merge the analysis. To handle last iteration (like in hmmer), we would need to extend loop peeling to support that. Even with that tree-ssa-loop-split has chance to be more informed and have better cost model. Let me see how many restrictions can be dropped it. Honza