From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id B200B3858D37 for ; Thu, 9 Nov 2023 11:54:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B200B3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B200B3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.220.28 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699530849; cv=none; b=a8S8XfcrHfT8eMYwxi745wAUNHsP155ZjF8olUdJjiUuXvn91aWhUtnziNmO691x6CXgOO+T4ffuXmrAEUg7wFxVI6O1Gnnp0cFRaCPZSrqQAyXDUmfNkh2/BWA9AFp+/r81P2qC4ZmFD0+gLS1gKjbiYegVbSZ1lipl8CF6Hrs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699530849; c=relaxed/simple; bh=TslVeK+IxbE2j3KCHTEgaXF5LvIrx+DKJafKya4CFxQ=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=UHPCkvX1fJf2PFAnq24RYDgXRCheSrNiRybKoa8IyS5sUIrCp6eCbb5dqGHF6smCUHTk4HfJNZVjPA+RP66VyOcc7YxCN6rDCMaNuoX/CY5lokPluKzSTONkS16GEaTxMXgQ3HadPb8pWSJYVSWC1rt6E7WhPicWmgfyRXAsYB4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id D0AE221980; Thu, 9 Nov 2023 11:54:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1699530846; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=58qD8xTh4uTLRuYqLnpJ3Ilk5VIq9umoFDbU4gWMJb8=; b=1ibe0WbZYsNz1DuWPitVHel+1J3gFK3Qi7iMOc1/Nd1laVUtNv+HUV2MBB+Oy0yk5twdCL TYmdAV8rzNJUSNq6bl3zxhEvgcryIALXmUcF/4lQQ8lBM395Rfm4OcfWGsM0z02/M3co1Y TGnoPFi+aSFExQVyMGLopZ3ZM2FpqtU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1699530846; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=58qD8xTh4uTLRuYqLnpJ3Ilk5VIq9umoFDbU4gWMJb8=; b=cajPf9eAAzkLvsPFmgRZ4vo3XuqCmcfrciKdZPxEjOqvq3RX17BjtdtESh9UrUUFH+JGCz 7sn+FnBiwR8i7MAg== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A268D2C405; Thu, 9 Nov 2023 11:54:06 +0000 (UTC) Date: Thu, 9 Nov 2023 11:54:06 +0000 (UTC) From: Richard Biener To: Tamar Christina cc: "gcc-patches@gcc.gnu.org" Subject: RE: [PATCH] tree-optimization/111950 - vectorizer loop copying In-Reply-To: Message-ID: References: <33fb3bb3-9548-4867-95f6-f7319bde2270@AMS1EPF00000043.eurprd04.prod.outlook.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Thu, 9 Nov 2023, Tamar Christina wrote: > > -----Original Message----- > > From: Richard Biener > > Sent: Thursday, November 9, 2023 9:24 AM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org > > Subject: RE: [PATCH] tree-optimization/111950 - vectorizer loop copying > > > > On Thu, 9 Nov 2023, Tamar Christina wrote: > > > > > > guard_bb = LOOP_VINFO_IV_EXIT (loop_vinfo)->dest; > > > > edge epilog_e = LOOP_VINFO_EPILOGUE_IV_EXIT (loop_vinfo); > > > > - guard_to = split_edge (epilog_e); > > > > + guard_to = epilog_e->dest; > > > > guard_e = slpeel_add_loop_guard (guard_bb, guard_cond, guard_to, > > > > skip_vector ? anchor : guard_bb, > > > > prob_epilog.invert (), > > > > @@ -3443,8 +3229,30 @@ vect_do_peeling (loop_vec_info loop_vinfo, > > > > tree niters, tree nitersm1, > > > > if (vect_epilogues) > > > > epilogue_vinfo->skip_this_loop_edge = guard_e; > > > > edge main_iv = LOOP_VINFO_IV_EXIT (loop_vinfo); > > > > - slpeel_update_phi_nodes_for_guard2 (loop, epilog, main_iv, > > > > guard_e, > > > > - epilog_e); > > > > + gphi_iterator gsi2 = gsi_start_phis (main_iv->dest); > > > > + for (gphi_iterator gsi = gsi_start_phis (guard_to); > > > > + !gsi_end_p (gsi); gsi_next (&gsi)) > > > > + { > > > > + /* We are expecting all of the PHIs we have on epilog_e > > > > + to be also on the main loop exit. But sometimes > > > > + a stray virtual definition can appear at epilog_e > > > > + which we can then take as the same on all exits, > > > > + we've removed the LC SSA PHI on the main exit before > > > > + so we wouldn't need to create a loop PHI for it. */ > > > > + if (virtual_operand_p (gimple_phi_result (*gsi)) > > > > + && (gsi_end_p (gsi2) > > > > + || !virtual_operand_p (gimple_phi_result (*gsi2)))) > > > > + add_phi_arg (*gsi, > > > > + gimple_phi_arg_def_from_edge (*gsi, epilog_e), > > > > + guard_e, UNKNOWN_LOCATION); > > > > + else > > > > + { > > > > + add_phi_arg (*gsi, gimple_phi_result (*gsi2), guard_e, > > > > + UNKNOWN_LOCATION); > > > > + gsi_next (&gsi2); > > > > + } > > > > + } > > > > + > > > > > > I've been having some trouble incorporating this change into the early break > > work. > > > My understanding is that here you've removed the lookup that > > > find_guard did and are assuming that the order between the PHI nodes > > > between loop->exit and epilog->exit are the same - sporadic virtual > > operands. > > > > > > But the loop->exit for early break has to materialize all PHI nodes > > > from the main loop into the epilog loop since we need them to restart the > > scalar loop iteration. > > > > > > This means that the number of PHI nodes between the first loop and the > > > second Loop are not the same, so we end up mis-linking phi nodes. > > > i.e. consider this loop > > > > > > https://gist.github.com/Mistuke/65d476b18f991772fdec159a09b81869 > > > > I don't see any multi-exits here? I think you need exactly the same PHIs you > > need for the branch to the epilogue, no? > > > > Ah it's a failing testcase but not one with an early break, > > > If you can point me to a testcase that fails on your branch I can try to have a > > look. > > I've updated the branch refs/users/tnfchris/heads/gcc-14-early-break > > Quite a few tests fail, a simple one is vect-early-break_5.c and vect-early-break_20.c > > But what you just said above makes me wonder.. at the moment before we have > differening amount because we require to have the loop counters and IVs as PHI nodes > such that vect_update_ivs_after_vectorizer can thread them through correctly as it > searches for PHI nodes. However for the epilog exit, those that are not live are not > needed. This is why we get different counts. > > Maybe.. the solution is that I need to do the same thing as vectorizable_live_operations > In that when vect_update_ivs_after_vectorizer is done I should either remove the PHI > nodes or turn them into simple assignments. Since they're always single value. > > Looking at a few examples that seems like it would fix the issue.. Does that sound right to you? Without diving deep into it I can't say for sure. I'd say any complex mangling of things should happen after we've set up the basic loop structure with prologue, epilogue end exit edges (I've hesitated with that virtual PHIs, thinking we should eventually delay removing it until we're ready with all the copying for example). Maybe vect_update_ivs_after_vectorizer is a similar thing. Richard. > Regards, > Tamar > > > > > which now goes wrong (throw that in a dotgraph viewer). > > > > > > I'm struggling to figure out how to handle this without doing a lookup. > > > > > > Any advice? > > > > > > Thanks, > > > Tamar > > > > > > > > > > /* Only need to handle basic block before epilog loop if it's not > > > > the guard_bb, which is the case when skip_vector is true. */ > > > > if (guard_bb != bb_before_epilog) > > > > -- > > > > 2.35.3 > > > > > > > -- > > Richard Biener > > SUSE Software Solutions Germany GmbH, > > Frankenstrasse 146, 90461 Nuernberg, Germany; > > GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG > > Nuernberg) > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)