From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by sourceware.org (Postfix) with ESMTPS id 51B0E388206C; Tue, 18 Jun 2024 06:17:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 51B0E388206C 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 51B0E388206C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718691467; cv=none; b=EGLE08sDJRxFu3cRKJIh6+qPtJELvDH2fkO71YJ/I6ZPwUgzYBn8c6QYoT62ixo1/eFmUHBpeI/vkaoMGDQ7tEkMtZ9oat0UI3Bugfz/B0ZgQXzozJRd2xgh438eLKK0Q6W0KjRVJmSHyauBq6maibW2qx6Kq0bUE7HdGbIgN/I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718691467; c=relaxed/simple; bh=zIxRU/SvC4WL5uQ5ebkUGgSFtlpluv/YhlKiDrup8Ow=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=QUdF9Mlj9bU0R0NSRiHvThdHp6wai05yWHQeEQI0EHANiSYpid7xeTWKYJE2qOJ18aw7kGga5mk17cxiHDqVPbYlMV9FQLj7li7isF638LH2A7pHG072nzwkh+woh9npfVOJTP4w4GsnZ3m9NJdNFkwwN9PIbnggJv7hBvM91yY= 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 0A77322788; Tue, 18 Jun 2024 06:17:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1718691456; 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=BarTWyoMich9GSbRpKoYa2MorOdyIT3U2eKNVHmhdTg=; b=jjxU2v29uFGOGhMMI/HUd9HDH7W/I6Y2j/rHHLyq+4QG1gdS1gg9yxLAK7QExLdr+iEJX/ O/4+OyBn5L+dBuc3C2Bnrvouw/0FHw1Bbcda/JEwWiDYuLteNwkO5vE5jNGjHgrgl0gkts KBIpPpvhDIu60PCTpGD/u10R+9ZrKkY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1718691456; 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=BarTWyoMich9GSbRpKoYa2MorOdyIT3U2eKNVHmhdTg=; b=kW2FnbhRZr3FFrp78g8L6eT+x8yTtokaBDeW62kONK2mlybnCnVuY+hbVX9tKpMTrymUXA o7F9wLLZ4iqEnsDA== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1718691455; 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=BarTWyoMich9GSbRpKoYa2MorOdyIT3U2eKNVHmhdTg=; b=QK3dAy6eeGjaXoXM6Nru0SKVDr2lShR9Yr0WWRvBMPW6kzx2r9kcKgl5dqbAH019Ln3zGv g10bBv3B5vC1IfJdb8Wn8n1n61xqlBIKaeFm+WJj6J/zip/V+bkNtuRAVpxsB2eHdscorn gYT/5+VBvWh7vah8AfMdhROlc9XmaNQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1718691455; 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=BarTWyoMich9GSbRpKoYa2MorOdyIT3U2eKNVHmhdTg=; b=lAO69MmP9gVQs7OEdCCSE/bSsIA+ZkB9D2owA0zXYbxH2p9cylH+IY3Dw9uRiqVE9SG8vj 2DCCBwmgYJaevgBg== Date: Tue, 18 Jun 2024 08:17:34 +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: 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-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)[-0.989]; 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,murzim.nue2.suse.org:helo] X-Spam-Score: -4.30 X-Spam-Level: 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,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 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. 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'll also note that we document vec_cmp{,u,eq} as having all zeros, > > all ones for the result while vcond_mask might only care for the MSB > > (it's documented to work on the result of a pre-computed vector > > comparison). > > Not sure how much the docs reflect reality. At least for SVE, > vec_cmp returns 0/1 results for vector boolean modes. Likewise for AVX512 though since all elements are 1 bit it's -1 as well. > But I think for integer comparison results, vec_cmp must produce 0/-1 > and vcond only accepts 0/-1. OK, so we adjust docs to constrain vector integer results but otherwise state the result is only used as predicate/mask operand. > > So this eventually asks for targets to work out the optimal sequence > > via combine helpers and thus eventually splitters to fixup invalid > > compare operators late? > > I really hope we can do this in late gimple & expand. Me as well. Richard. > Thanks, > Richard > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)