From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 9DD2B383E819 for ; Wed, 10 Jun 2020 08:51:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9DD2B383E819 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mliska@suse.cz X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C7900AC2D; Wed, 10 Jun 2020 08:51:27 +0000 (UTC) Subject: Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions. To: Richard Biener Cc: Segher Boessenkool , GCC Patches , Richard Sandiford , David Edelsohn References: <20200529153933.GW31009@gate.crashing.org> <20200529170936.GY31009@gate.crashing.org> <20200529173758.GA31009@gate.crashing.org> <20200530130801.GD31009@gate.crashing.org> <16e3957c-e390-5984-b14e-dd3c70c3bd1c@suse.cz> <20200603182734.GA31009@gate.crashing.org> <3932cb72-4529-6755-bb35-45e11f1c3382@suse.cz> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: Date: Wed, 10 Jun 2020 10:51:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 08:51:26 -0000 On 6/9/20 3:42 PM, Richard Biener wrote: > On Mon, Jun 8, 2020 at 1:04 PM Martin Liška wrote: >> >> Hello. >> >> Thank you for the approval. There's the patch that defines 4 new DEF_INTERNAL_OPTAB_FN. >> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >> It also builds on ppc64le-linux-gnu. >> >> Ready to be installed? > > The ChangeLog refers to DEF_INTERNAL_OPTAB_CAN_FAIL which is no longer there. Sure. > > Can you put the isel pass to a separate file please? Yes. > > So this is a first step towards sanitizing VEC_COND_EXPR. There were followups > mentioned, namely a) enforcing that VEC_COND_EXPR constraint everywhere, > b) isel vector comparisons at the same time since expansion has a > vec_cond fallback I'm planning to work on the follow up. > > There's > > + /* ??? If we do not cleanup EH then we will ICE in > + verification. But in reality we have created wrong-code > + as we did not properly transition EH info and edges to > + the piecewise computations. */ > + if (maybe_clean_eh_stmt (gsi_stmt (gsi)) > + && gimple_purge_dead_eh_edges (bb)) > + cfg_changed = true; Hm, I've tried to comment the code in both ISEL and expansion and I can't find a test-case that would trigger a verification error (in vect.exp and i386.exp). Can you come up with something that will trigger the code? > > which of course is bad. It's the comparison that can throw and I guess current > RTL expansion manages to cope by find_many_sub_bbs and friends. But we > need to get this correct on GIMPLE here. Note I find it odd this only triggers > during ISEL - it should trigger during the lowering step which splits > the comparison > from the VEC_COND_EXPR. An appropriate fix at lowering time would be to > insert the VEC_COND_EXPR w/o the condition on the normal outgoing edge > and keep the comparison in place of the original VEC_COND_EXPR, > moving EH info from the VEC_COND_EXPR to the comparison. Ah ok, so it's about correction of EH.. Martin > > I think we need to fix that before merging. > > Thanks, > Richard. > >> Thanks, >> Martin