From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2a07:de40:b251:101:10:150:64:1]) by sourceware.org (Postfix) with ESMTPS id 059963898391; Fri, 21 Jun 2024 09:53:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 059963898391 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 059963898391 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718963600; cv=none; b=famVJIHaTUJ2+z4J9zEwAT9fwxf59ZRHvpMIrzS51EmnAu5hm8vlkfwI49tulJKMHIz4QhAIWWfb+U1E08+O7mdowaD/RGDQS6z80KskUAcF+MDXn+BWOdTMYGI/rXOwynzfGo1v3galsh95KVPlAktjZNAh2Fwg5kOpD3j05TU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718963600; c=relaxed/simple; bh=gCHALjpw9vdLlf9Zsiv6c0gSU0E3oJqR5y8TkPf959M=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=lPcxA1/fDjBuU+ltyIVqmrOhnID8TuPwrbDtB7zohU5EjQ+stjs+IyZuva+QtMAl4DJXzFg94GLVr49z+8zq91z039NDSOVknpK8o5z3ebbFYw6NyLxML9KRe8SEQSZZrme5ybEZ+QAb2carW5A4oGzcux6iJN00OE6+iTJ3sJw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from murzim.nue2.suse.org (unknown [10.168.4.243]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id E82EC219A1; Fri, 21 Jun 2024 09:53:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1718963597; 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=QNENKNakGA0Fd8VqW1n06vkrsr/ftfmRNnIEZgvJHFc=; b=W20RzjXCFuVLR3+XqufZG3tTqtusaubbGLPtvTDXwhaFXv/eS4i0RKoGNNSEF7/nFuLQsS Hg6NFK/SOS9dK40tEYtAdPiz7hRQyoJU2t1eP3tc7LNj7LUwqh5bjYQPMEyXWb0k3oTosU CZsFVSoC5ImM1Re9suSqIjEeIw11Hqo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1718963597; 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=QNENKNakGA0Fd8VqW1n06vkrsr/ftfmRNnIEZgvJHFc=; b=knVcctYvL9xn8fJ2mlqNWOcC9BloDcI1DRiDWsoh3sjgVje5MktmzByOrtqrJLMFmVBpHP MggI5iG95b34NXBw== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1718963597; 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=QNENKNakGA0Fd8VqW1n06vkrsr/ftfmRNnIEZgvJHFc=; b=W20RzjXCFuVLR3+XqufZG3tTqtusaubbGLPtvTDXwhaFXv/eS4i0RKoGNNSEF7/nFuLQsS Hg6NFK/SOS9dK40tEYtAdPiz7hRQyoJU2t1eP3tc7LNj7LUwqh5bjYQPMEyXWb0k3oTosU CZsFVSoC5ImM1Re9suSqIjEeIw11Hqo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1718963597; 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=QNENKNakGA0Fd8VqW1n06vkrsr/ftfmRNnIEZgvJHFc=; b=knVcctYvL9xn8fJ2mlqNWOcC9BloDcI1DRiDWsoh3sjgVje5MktmzByOrtqrJLMFmVBpHP MggI5iG95b34NXBw== Date: Fri, 21 Jun 2024 11:53:16 +0200 (CEST) From: Richard Biener To: Richard Sandiford 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 In-Reply-To: Message-ID: <203sp44s-3q4q-q199-5088-n4p1s4qnos65@fhfr.qr> References: <20240614103115.1DB0213AB1@imap1.dmz-prg2.suse.org> <271q309s-rqn4-81n9-8r3p-799q36on9356@fhfr.qr> <11snn047-o533-9q87-os1r-5rsn28s09641@fhfr.qr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -4.30 X-Spam-Level: X-Spamd-Result: default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_SEVEN(0.00)[10]; FROM_HAS_DN(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email] X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP 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, 20 Jun 2024, Richard Sandiford wrote: > 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. I agree that as we have to handle completely unsupported cases in vector lowering anyway it's reasonable to try to force only supported ops after that. Note that when targets stop to advertise not supported compares then the vectorizer likely needs adjustments as well. We can of course put some common logic into the middle-end like making the expand_vec_cmp_expr_p function take additional optional arguments to indicate whether swapping operands or inverting the condition code makes the comparison supported. Do you know any target off head that restricts vec_cmp support via predicates? I'm not exactly sure how do implement such predicate and having a patch for a target with some vector coverage would be nice for implementing this. I'd start with the vector lowering bits obviously, I suspect there's quite some patterns in match.pd that need guarding in case there's no existing target doing such predication. Richard.