From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 280B13858D28 for ; Wed, 7 Sep 2022 16:30:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 280B13858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x429.google.com with SMTP id 145so15183730pfw.4 for ; Wed, 07 Sep 2022 09:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=5MI1hdAThBgRo7Haz6y2aQIAgs/mYgo6WfGscrfngqA=; b=q4x6UUjNnvG8/OFFkHfwqRvvl6yF+QGTxKwWinKoLH7qHgEejyZ4Vzx219Chj6lWVt I+3BhPFFo9n89Uj/qPr84yIaKGkUwrVtXigkgy0WKrjlL8gRJtcBwXSH2cy4d8UwlPX8 3hM97Yo+OUZEp1KF9BM9KnXdEKgfPVXEZ+hCyfxjc06yENXwXT6Os3EuDDPaUVTecBPT 380iHD/fLbYg7Wd0m6qJQBp9LI4Smt0tW8n6Lk2qdP8OYZM3K7ETBJgEeiLYcQ/LAlzp 2WCN6qG4BTTTlQ+WFR5ZUpJ7nRXEHzVyhgvWCtx5OEGBkJgttLJaCWTsZIwELwAc0cg1 eFlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=5MI1hdAThBgRo7Haz6y2aQIAgs/mYgo6WfGscrfngqA=; b=7K3YlTEr9NMIkJJ2rfiJdLVh97Hvi6eddmpGpfYwi5oCPWU/NQSE1/hBMWHK0swQuV iOdlGKVSCV3M188egCSHo4EgzPraQGn/Sw7hNaUb9lhwRq9bn/Y8rxasdygeyjyqqK94 wrL4Xa5BG4B8zgTVdIZZy6glUgnaVi/dIaCCV7wc1QJqmLyIXOgbtJOsztsU7iwwV7k1 fQ27praH5kO8qPNpw1h045UMCn9286C8Tdv9kc3eSPQ/RtNuKrhzN9znCGKZygXmPkM5 yLhGuT7gw9wT54IWESAv2ei0yzETII2GgwkRzvZWfoLs3jrsAdEUyiLKNNEJTSH6tyZW jOWg== X-Gm-Message-State: ACgBeo3jo9GDevRL8m4jKD5tHYASzOSzVZTraa5NSp6uqFASE8ZoZPC6 Sp+1DRjEI19/D4+ne5dWL30nyELCbKcj1g== X-Google-Smtp-Source: AA6agR5jY+fpJweozm7GqGxEY853g6oIr8x/gO84RiPnCQuwlkuG4Kd2D16hyuGhlXEWMbioI/56tg== X-Received: by 2002:a63:5b16:0:b0:42a:8c1b:819a with SMTP id p22-20020a635b16000000b0042a8c1b819amr3984787pgb.424.1662568215425; Wed, 07 Sep 2022 09:30:15 -0700 (PDT) Received: from [172.31.0.204] (c-73-98-188-51.hsd1.ut.comcast.net. [73.98.188.51]) by smtp.gmail.com with ESMTPSA id f7-20020a635547000000b0042b117e8bf8sm10839187pgm.23.2022.09.07.09.30.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Sep 2022 09:30:14 -0700 (PDT) Message-ID: Date: Wed, 7 Sep 2022 10:30:13 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH] expand: Convert cst - x into cst xor x. Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <938fbb10-926f-a588-1e90-1d7b72d1d7f8@linux.ibm.com> <3d928191-a2f5-f314-c03b-d4e590282ce9@linux.ibm.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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 9/7/2022 6:45 AM, Richard Biener via Gcc-patches wrote: > On Wed, Sep 7, 2022 at 2:20 PM Robin Dapp wrote: >>> The question is really whether xor or sub is "better" statically. I can't >>> think of any reasons. On s390, why does xor end up "better"? >> There is an xor with immediate (as opposed to no "subtract from >> immediate") which saves an instruction, usually. On x86, I think the >> usual argument for xor is that it's shorter (if flags etc. are not needed). >> >> It's not that I don't want to implement it in the backend, just that I >> understood the original PR in a way that it would make sense to have >> this conversion available for more targets. If there are too many >> confounding factors that prevent this situation from being statically >> costed properly, then sure, not much use in implementing it generally. > Do we have evidence that targets properly cost XOR vs SUB RTXen? Probably not.  And I have vague memories of some targets not having xor with immediate, but which did have more expressive sub instructions (so the opposite of the situation on s390). Checking costs seems like a very sensible thing to do though and if targets need adjustment, then we can cope. > > It might actually be a reload optimization - when the constant is > available in a register use 'sub', when it needs to be reloaded > use 'xor'? Perhaps.  The question is finding out of the constant is actually available in a register.  We don't do a particularly good job at that. > > That said, I wonder if the fallout of changing some SUB to XOR > is bigger than the benefit when we do it early (missed combines, etc.)? Quite possibly -- though I doubt it matters in practice. jeff