From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by sourceware.org (Postfix) with ESMTPS id 4C76A3858C33 for ; Tue, 9 Jan 2024 10:06:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4C76A3858C33 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 4C76A3858C33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704794806; cv=none; b=OxI8K2K4MQiHXWtksdkihw1QmBT2jbwjD4n2JpoWKtKABqqrpXNmWjRec9VApB27QtpFXzSTWtpuAiZjkCX2Mo8kECM6/5g+lPpfLfl8oSLeCnY9SUoSf81XSLkaph5o1XScD4j+TOWVVtgBDUCj+N3/pGTZAmQsWIR42b0vcwU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704794806; c=relaxed/simple; bh=SgylWEv+vi+JTdJHBi6wEPRNir8HYCCHDrCBeaDHBpc=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=M9wAvV2aDBxIBtG4GeGCLKgZb3W9cBqAp5H9bQKIZd5sARkZWMxeni1dTNnQ3sH3YDWqtz7COVNtypYYCxICFnoZwOmNXCDX9CoCTrEbgpAP/T9T6S7f39uIvnmpgneThDoRs9HmhsVPHm0Aki/5suPQiNu49MpYtFTZHklv+xw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.4.150] (unknown [10.168.4.150]) (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-out2.suse.de (Postfix) with ESMTPS id DB5781F7F4; Tue, 9 Jan 2024 10:06:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1704794801; 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=loSN58hTHdHEImbwvtx4RGAtsTIqn39Qhm7YYsJ9eBw=; b=IaYU2ySa83re1zcGKL4J/7lD2jaDWRraogwdFC5fuIu5WAwZvfCZ3Zpz3/V3EYU0LBnbcr xyug3Nl+JxMnCblDKdWRHnh4UqnLo8F57LbmASmAHg8d7fcDsz/vQz9NmevtfBqULBFaCg tKK7d85/VCJt0v8eqfMtvD6qy1zsDyY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1704794801; 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=loSN58hTHdHEImbwvtx4RGAtsTIqn39Qhm7YYsJ9eBw=; b=2bdID+c+7tQEUfaNQoIdLglfu9XVDe3fGWldTH5OFWTYRVu2BZk0b3wlGuNc6Pk4y+XyqH 0f+0+0E1FZ+Dk3BQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1704794801; 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=loSN58hTHdHEImbwvtx4RGAtsTIqn39Qhm7YYsJ9eBw=; b=IaYU2ySa83re1zcGKL4J/7lD2jaDWRraogwdFC5fuIu5WAwZvfCZ3Zpz3/V3EYU0LBnbcr xyug3Nl+JxMnCblDKdWRHnh4UqnLo8F57LbmASmAHg8d7fcDsz/vQz9NmevtfBqULBFaCg tKK7d85/VCJt0v8eqfMtvD6qy1zsDyY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1704794801; 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=loSN58hTHdHEImbwvtx4RGAtsTIqn39Qhm7YYsJ9eBw=; b=2bdID+c+7tQEUfaNQoIdLglfu9XVDe3fGWldTH5OFWTYRVu2BZk0b3wlGuNc6Pk4y+XyqH 0f+0+0E1FZ+Dk3BQ== Date: Tue, 9 Jan 2024 11:01:41 +0100 (CET) From: Richard Biener To: Uros Bizjak cc: Andrew Pinski , "gcc-patches@gcc.gnu.org" , Jeff Law Subject: Re: [PATCH] match.pd: Convert {I, X}OR of two values ANDed with alien CSTs to PLUS [PR108477] In-Reply-To: Message-ID: References: <69pn947p-0q52-1snr-8267-094n4n541r03@fhfr.qr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Level: Authentication-Results: smtp-out2.suse.de; none X-Spamd-Result: default: False [-4.28 / 50.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.18)[-0.900]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[gmail.com,gcc.gnu.org]; FUZZY_BLOCKED(0.00)[rspamd.com]; BAYES_HAM(-3.00)[100.00%] X-Spam-Level: X-Spam-Score: -4.28 X-Spam-Status: No, score=-5.3 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 Tue, 9 Jan 2024, Uros Bizjak wrote: > On Tue, Jan 9, 2024 at 10:44?AM Richard Biener wrote: > > > > On Tue, 9 Jan 2024, Uros Bizjak wrote: > > > > > On Tue, Jan 9, 2024 at 9:58?AM Richard Biener wrote: > > > > > > > > On Mon, 8 Jan 2024, Uros Bizjak wrote: > > > > > > > > > On Mon, Jan 8, 2024 at 5:57?PM Andrew Pinski wrote: > > > > > > > > > > > > On Mon, Jan 8, 2024 at 6:44?AM Uros Bizjak wrote: > > > > > > > > > > > > > > Instead of converting XOR or PLUS of two values, ANDed with two constants that > > > > > > > have no bits in common, to IOR expression, convert IOR or XOR of said two > > > > > > > ANDed values to PLUS expression. > > > > > > > > > > > > I think this only helps targets which have leal like instruction. Also > > > > > > I think it is the same issue as I recorded as PR 111763 . I suspect > > > > > > BIT_IOR is more of a Canonical form for GIMPLE while we should handle > > > > > > this in expand to decide if we want to use PLUS or IOR. > > > > > > > > > > For the pr108477.c testcase, expand pass expands: > > > > > > > > > > r_3 = a_2(D) & 1; > > > > > p_5 = b_4(D) & 4294967292; > > > > > _1 = r_3 | p_5; > > > > > _6 = _1 + 2; > > > > > return _6; > > > > > > > > > > The transformation ( | -> + ) is valid only when CST1 & CST2 == 0, so > > > > > we need to determine values of constants. Is this information > > > > > available in the expand pass? > > > > > > > > If there's single-uses then TER makes this info available. > > > > > > > > > IMO, the transformation from (ra | rb | cst) to (ra + rb + cst) as in > > > > > the shown testcase would be beneficial when constructing control > > > > > register values (see e.g. mesa-3d). We can use LEA instead of OR+ADD > > > > > sequence in this case. > > > > > > > > The other possibility is to expose LEA as optab and making GIMPLE > > > > instruction selection generate a direct internal function for that > > > > (that would be the "better" way). There is LEA-like &TARGET_MEM_REF > > > > but that has constraints on the addends mode (ptr_mode) which might > > > > not fit what the target can do? Otherwise that would be an existing > > > > way to do this computation as well. > > > > > > I think there is no need for a new optab. If we can determine at > > > expand time that ANDed values are fed to the IOR/XOR expressions, then > > > we can check the constants and emit PLUS RTX instead. RTL combine pass > > > will then create LEA instruction from separate PLUS instructions. > > > > > > So, we can emit: > > > > > > op0 = and (a, CST1) > > > op1 = and (b, CST2) > > > op2 = plus (op0, op1) > > > > > > RTX sequence for (a & CST1) | (b & CST2) when CST1 & CST2 == 0 > > > > > > and > > > > > > op0 = and (a, CST1) > > > op1 = plus (op0, CST2) > > > > > > RTX sequence for (a & CST1) | CST2 when CST1 & CST2 == 0 > > > > > > The above transformation is valid for IOR and XOR. > > > > > > x86 can't combine IOR/XOR in any meaningful way, but can combine the > > > sequence of PLUS (together with MULT) RTXes to LEA. > > > > Btw, this looks like a three-insn combination even with IOR so a > > pattern for this case would work as well? > > IIUC the question: x86 does not have three-input IOR, but we want to > emulate it with LEA (three-input PLUS, but one of the arguments has to > be constant). But couldn't you have a define_insn matching LEA but with IOR instead of PLUS (and with the appropriate constraints?). Maybe it could also be combine trying PLUS instead of IOR if that's possible (looking at the constants). > We can do the conversion only when masking constants do > not intersect. *However*, the original problem is that the compiler is > converting PLUS to IOR, preventing the generation of LEA. As shown in > the original PR, we would like to *prevent* the conversion from PLUS > to IOR on x86, because it interferes with (a & CST1 + b & CST2 + CST3) > - we would really want to generate LEA in this case. I'm throwing in the argument that the user could have written a & CST1 | b & CST2 + CST3 as well. > > Deciding whether to use PLUS or IOR at RTL expansion time would > > need to somehow figure out what's better for the target in question. > > I'm not sure how to do that? > > I think that a target hook would be needed. In addition to x86, Jeff > presented a very specialized use case for RISC-V that can't be > described otherwise. > > Uros. > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)