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 93CBD3858C33 for ; Tue, 9 Jan 2024 09:44:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 93CBD3858C33 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 93CBD3858C33 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=1704793492; cv=none; b=fOCNjiCz5PrhA7VfauNdNWmE6Y6cIM/rY1V/npJL3Gx4uKGs7Xs2A7N2AsXEHcdv5PgX9s5LXffqAlOGn21VbXLc+Ccw2HEMfA3pNI3jUQSfLhgt65FKZgZYRAwbeIw853AaEGIN1yWF9qFYBDJD3qTEvYeera2LEU0HjOagcsI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704793492; c=relaxed/simple; bh=KDJl1cAiYxi/UPWGDArr9g42XzW0WsMtpZPKAQdPoh4=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=ESGFXdLAQrmsnazZwGI3IyV67zdOFY2DrujWIkVTcs0e3Fe7ulPdLCCFG1H8wiHtWPENw9OTnEIxlk/e3wl9mW9d9QBxMK6n1wwUL0DfWUvLkoQoHWNC4uS3h4iy2s8dX1R4RDEfihCop83QJxGm8hgiE2EezhMqePjEOh+zCh0= 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 7F0FF1F7F2; Tue, 9 Jan 2024 09:44:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1704793489; 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=KchuteZjq8p26oS1BMTigvLzZUTbVoFIDc2uW6f+ek4=; b=V+W+N4IDxBZG9iA0N8Gy8B7Co/EqqswiZ1DEfowZLDszAv9u4qa4sql23++it7tckQifOX WBUo4H/yQWljilFo8R3IAurrVZV69yTIeV55ezeS62tewhZAO0ZVorcJd/YtcBEqBCJ02L 2sMd2vzm2dxaDk+KpKMgS3//TbR+M+M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1704793489; 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=KchuteZjq8p26oS1BMTigvLzZUTbVoFIDc2uW6f+ek4=; b=0LfMUl3OqNI+SBqm21TeygGME84QaBNWWjWQAqbIv15XVoYQY0eU7CoU/hhSfPtEQXGkRd i+YF1mNXo5kW/QDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1704793489; 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=KchuteZjq8p26oS1BMTigvLzZUTbVoFIDc2uW6f+ek4=; b=V+W+N4IDxBZG9iA0N8Gy8B7Co/EqqswiZ1DEfowZLDszAv9u4qa4sql23++it7tckQifOX WBUo4H/yQWljilFo8R3IAurrVZV69yTIeV55ezeS62tewhZAO0ZVorcJd/YtcBEqBCJ02L 2sMd2vzm2dxaDk+KpKMgS3//TbR+M+M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1704793489; 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=KchuteZjq8p26oS1BMTigvLzZUTbVoFIDc2uW6f+ek4=; b=0LfMUl3OqNI+SBqm21TeygGME84QaBNWWjWQAqbIv15XVoYQY0eU7CoU/hhSfPtEQXGkRd i+YF1mNXo5kW/QDA== Date: Tue, 9 Jan 2024 10:39:50 +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: <69pn947p-0q52-1snr-8267-094n4n541r03@fhfr.qr> References: 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.899]; 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 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? 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? Richard.