From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 37E46389000C; Thu, 20 Jun 2024 18:38:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 37E46389000C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 37E46389000C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718908736; cv=none; b=HKT1fw+PfSbxGDUTnBv3ONNZy7m5qSMuJdBfPYNSADE3BAYo2+nGY6m4cWPktguX/yJj5cvnp3mdFFqUxUvgpGbQYjUtAmwBldAUk11eDN5jzHHUpc7JJAMs5x0w/e2ezhN2HcN2AETfwXk4PcCveMNGtoeSmOQL58uqgP5DeGM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718908736; c=relaxed/simple; bh=WYtIaSqae/SI8/WBL+W/OMYjW3zF4mpX1mQ/1Uk7Eok=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=cq63ihv5Pg0qJdWVtvM7YgNniauUqODxSze02upnAABVtmRdLK0WTjND4H5iLubC/Ls49AfyndejPQ1IBnDq0+tPQ+wITKYlC+oD131McHQatevb5cO68xn3J45n/YDaevguGE/TZqlkqF45B/RzwkMmHM16pxGf80NrbA/nYGM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 31097DA7; Thu, 20 Jun 2024 11:39:18 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1A5C13F6A8; Thu, 20 Jun 2024 11:38:51 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,gcc-patches@gcc.gnu.org, hongtao.liu@intel.com, ebotcazou@libertysurf.fr, krebbel@linux.ibm.com, linkw@gcc.gnu.org, syq@gcc.gnu.org, xuchenghua@loongson.cn, ams@baylibre.com, richard.earnshaw@arm.com, richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, hongtao.liu@intel.com, ebotcazou@libertysurf.fr, krebbel@linux.ibm.com, linkw@gcc.gnu.org, syq@gcc.gnu.org, xuchenghua@loongson.cn, ams@baylibre.com, richard.earnshaw@arm.com Subject: Re: [PATCH] middle-end/114189 - drop uses of vcond{,u,eq}_optab References: <20240614103115.1DB0213AB1@imap1.dmz-prg2.suse.org> <271q309s-rqn4-81n9-8r3p-799q36on9356@fhfr.qr> <11snn047-o533-9q87-os1r-5rsn28s09641@fhfr.qr> Date: Thu, 20 Jun 2024 19:38:44 +0100 In-Reply-To: (Richard Biener's message of "Tue, 18 Jun 2024 08:17:34 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-13.8 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: Richard Biener writes: > On Mon, 17 Jun 2024, Richard Sandiford wrote: > >> Richard Biener writes: >> > On Fri, 14 Jun 2024, Richard Biener wrote: >> > >> >> On Fri, 14 Jun 2024, Richard Sandiford wrote: >> >> >> >> > Richard Biener writes: >> >> > > On Fri, 14 Jun 2024, Richard Sandiford wrote: >> >> > > >> >> > >> Richard Biener writes: >> >> > >> > The following retires vcond{,u,eq} optabs by stopping to use them >> >> > >> > from the middle-end. Targets instead (should) implement vcond_mask >> >> > >> > and vec_cmp{,u,eq} optabs. The PR this change refers to lists >> >> > >> > possibly affected targets - those implementing these patterns, >> >> > >> > and in particular it lists mips, sparc and ia64 as targets that >> >> > >> > most definitely will regress while others might simply remove >> >> > >> > their vcond{,u,eq} patterns. >> >> > >> > >> >> > >> > I'd appreciate testing, I do not expect fallout for x86 or arm/aarch64. >> >> > >> > I know riscv doesn't implement any of the legacy optabs. But less >> >> > >> > maintained vector targets might need adjustments. >> >> > >> > >> >> > >> > I want to get rid of those optabs for GCC 15. If I don't hear from >> >> > >> > you I will assume your target is fine. >> >> > >> >> >> > >> Great! Thanks for doing this. >> >> > >> >> >> > >> Is there a plan for how we should handle vector comparisons that >> >> > >> have to be done as the inverse of the negated condition? Should >> >> > >> targets simply not provide vec_cmp for such conditions and leave >> >> > >> the target-independent code to deal with the fallout? (For a >> >> > >> standalone comparison, it would invert the result. For a VEC_COND_EXPR >> >> > >> it would swap the true and false values.) >> >> > > >> >> > > I would expect that the ISEL pass which currently deals with finding >> >> > > valid combos of .VCMP{,U,EQ} and .VCOND_MASK deals with this. >> >> > > So how do we deal with this right now? I expect RTL expansion will >> >> > > do the inverse trick, no? >> >> > >> >> > I think in practice (at least for the targets I've worked on), >> >> > the target's vec_cmp handles the inversion itself. Thus the >> >> > main optimisation done by targets' vcond patterns is to avoid >> >> > the inversion (and instead swap the true/false values) when the >> >> > "opposite" comparison is the native one. >> >> >> >> I see. I suppose whether or not vec_cmp is handled is determined >> >> by a FAIL so it's somewhat difficult to determine this at ISEL time. >> >> In principle we could say that the predicates should accept only the >> conditions that can be done natively. Then target-independent code >> can apply the usual approaches to generating other conditions >> (which tend to be replicated across targets anyway). > > Ah yeah, I suppose that would work. So we'd update the docs > to say predicates are required to reject not handled compares > and otherwise the expander may not FAIL? > > I'll note that expand_vec_cmp_expr_p already looks at the insn > predicates, so adjusting vector lowering (and vectorization) to > emit only recognized compares (and requiring folding to keep it at that) > should be possible. > > ISEL would then mainly need to learn the trick of swapping vector > cond arms on inverted masks. OTOH folding should also do that. Yeah. > Or do you suggest to allow all compares on GIMPLE and only fixup > during ISEL? How do we handle vector lowering then? Would it be > enough to require "any" condition code and thus we expect targets > to implement enough codes so all compares can be handled by > swapping/inversion? I'm not sure TBH. I can see the argument that "canonicalising" conditions for the target could be either vector lowering or ISEL. If a target can only do == or != natively, for instance (is any target like that?), then I think it should be ok for the predicates to accept only that condition. Then the opposite != or == could be done using vector lowering/ISEL, but ordered comparisons would need to be lowered as though vec_cmp wasn't implemented at all. Something similar probably applies to FP comparisons if the handling of unordered comparisons is limited. And if we do that, it might be easier for vector lowering to handle everything itself, rather than try to predict what ISEL is going to do. Thanks, Richard