From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id F2184385456C for ; Thu, 17 Nov 2022 22:44:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F2184385456C 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-pj1-x1033.google.com with SMTP id d13-20020a17090a3b0d00b00213519dfe4aso3380551pjc.2 for ; Thu, 17 Nov 2022 14:44:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+O0Fv4SZVmxxvmuiuO+D/b9ku+7cKH8t/knXHmkyJ3w=; b=jZs6zjzu6qkvwmEtQPQDQzKbiB6cCKKAiwA1ntnj5cPqD4RJ1BVKcCe1mrpmVYy2rV AJzfpPI4F/yYKXn1TF+lvkC/zSvPRqg7v7HbS36fu+5yvf++4Xjo+psCLweMDR+bqOB/ b0r42msLjHKo1U3iwOwlrvI5OhHhTY8Fb1DF3tM888dvxYx+kUhEcLU3exJVzcxC2MTJ gI788dHDAWNu3T7SZ+Nib6F7rLJ6KiHoqHGktwkr8/m4M7YyvUg1YGlUTnnbIbyQdjBP 0tA0jxUHdXr5ghNQNx7TTUNqphw55blDzMdc0/aAiXPKniTaCmihSPn4kTE7yIlfLAli /UNg== 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:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+O0Fv4SZVmxxvmuiuO+D/b9ku+7cKH8t/knXHmkyJ3w=; b=OzuIjIVb4R1LmGyIIhjFanlHlhtQiVaNy4O3mYMJD5V4L3m9rk9F9Ef2Agn2ntcMNE xvEb5Fkpu7oUEh62M5V/fdQxR48LSJi5jHf2s40CUwYu7rPqca3lj8x0Qky87GW1Yu1Z zd3H5s5lSbPITiwSQtcocXOQT4G6uwgSIxSCLI986cxZ+DJP2jJA6PJaVio71b/vnSlQ 8QyQkHBfV+Yc6mT4lObzmD++e9iIvxW3x/5Jn9jMx+IuOkqIrEYO0TDbgGPnoioF+Us4 ut7OysLcfJCpG2WeonP1iNd2zZLIoD4V/bXjndKX9OP9+OhEu8zGcP5lenVC+1BSwSOz Bdog== X-Gm-Message-State: ANoB5pmoVs+A53pESWJPVRd7p8dsAi/lnudNGFwCKF4CE+zIbVfCg3jC ZluC18W8oR9d4lBsv2k8BiA= X-Google-Smtp-Source: AA0mqf6IE9cErsHl9CkK+GXs9WX/hCE/AZTbmUGvbaw8opk4z7FluemcRGf8k57F72g4ccd14QU1pQ== X-Received: by 2002:a17:902:ec8d:b0:188:7dca:6f41 with SMTP id x13-20020a170902ec8d00b001887dca6f41mr4677672plg.72.1668725073822; Thu, 17 Nov 2022 14:44:33 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id n62-20020a622741000000b0056b88187374sm1667018pfn.85.2022.11.17.14.44.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Nov 2022 14:44:33 -0800 (PST) Message-ID: <41d536f8-0f5d-d7fa-1b9d-37d88ade6640@gmail.com> Date: Thu, 17 Nov 2022 15:44:31 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] RISC-V: branch-(not)equals-zero compares against $zero Content-Language: en-US To: Philipp Tomsich , gcc-patches@gcc.gnu.org Cc: Vineet Gupta , Kito Cheng , Jeff Law , Palmer Dabbelt , Christoph Muellner References: <20221108195509.2701313-1-philipp.tomsich@vrull.eu> From: Jeff Law In-Reply-To: <20221108195509.2701313-1-philipp.tomsich@vrull.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 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 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 11/8/22 12:55, Philipp Tomsich wrote: > If we are testing a register or a paradoxical subreg (i.e. anything that is not > a partial subreg) for equality/non-equality with zero, we can generate a branch > that compares against $zero. This will work for QI, HI, SI and DImode, so we > enable this for ANYI. > > 2020-08-30 gcc/ChangeLog: > > * config/riscv/riscv.md (*branch_equals_zero): Added pattern. I've gone back an forth on this a few times.  As you know, I hate subregs in the target descriptions and I guess I need to extend that to querying if something is a subreg or not rather than just subregs appearing in the RTL. Presumably the idea behind rejecting partial subregs is the bits outside the partial is unspecified, but that's also going to be true if we're looking at a hardreg in QImode (for example) irrespective of it being wrapped in a subreg. I don't doubt it works the vast majority of the time, but I haven't been able to convince myself it'll work all the time.  How do we ensure that the bits outside the mode are zero?  I've been bitten by this kind of problem before, and it's safe to say it was exceedingly painful to find. Jeff