From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id DCD073858D20 for ; Sat, 19 Nov 2022 16:48:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DCD073858D20 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-pl1-x629.google.com with SMTP id y10so5934331plp.3 for ; Sat, 19 Nov 2022 08:48:01 -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=+THaLHW3rZTuhqKiciaFwTAiBDGBFffzom8SEGh7lUg=; b=qNhXuVMljMSWhTYIu1QhuNu5V7mqBwDhQ4hovPtEY3WbdN5hNvK584G4H/4Ay+vl4Z PgGEh2Y2ePacMJ1H0tpQdGbC3bHQAOEBOgHdK4tl9ljiEMTKU9kFm+mtcqMQ+8WANNaX UjItit6DeSoYhJc1M5Gn8WC+Qu+QQjsN2KPqv0wcoG0Os7VDCRTFpwTJaWH0u0CoQOkW rLgm5xZDL0n214rWzhKD58fNVwjqN4C4+eq8riJN9dUQdjZYrKDpnBOp27zoXDgby+j/ DAzcOjqXjWwUcPxkbO1d3HtcSEJ5j9HiA7FRrkIgKKpzre2HglJg/VgQamD98ePmmuX+ 6Llg== 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=+THaLHW3rZTuhqKiciaFwTAiBDGBFffzom8SEGh7lUg=; b=KLpJ4373ca33WXuP8h5I5ihybRLfCp5Z2SWp3ZUnM45n36hAv2++CCjgzWMbbhvS0F 3lw/Hl+4CmoHzhpDYpY4dJuH6eb/cOxU87dDzWzYpboqzPs4BbdqQI6uUWJVSffKt/k+ req+Kg4RbvwbxE+xD2Q/A27nMbH5rbL/AYtltc3de2/1gH8RkvqQb+9HpR2MAQmgQ772 jg47/9LrY263O+hYQCc9isUVxsYfjOVArM5JgfW3HA/bRaZSzrGyQlHXzZkcOZQU8pBk TCK8cJIe+t6FrVKCbgJwpP805IpZSK4ZouBiYnr9Q6hCuR3GkhAbxyubQC7H0Z1Ga4s3 sW4g== X-Gm-Message-State: ANoB5pmAGV5xMkWrfna37+XN3fXerX0kb2uAZh68hsgURzLPTc5L67+U Rbx6jnhXBrAD7rLaDnyu6K4= X-Google-Smtp-Source: AA0mqf7dWK06tG+kUNScXcjjTbwDWAjS5Vg7vqvM+Tqt5aLBJMhI1cLP4TI009GtafbS0FwcTWBfiQ== X-Received: by 2002:a17:902:aa88:b0:186:905e:f964 with SMTP id d8-20020a170902aa8800b00186905ef964mr1976613plr.162.1668876480650; Sat, 19 Nov 2022 08:48:00 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id r11-20020a170902c60b00b00188b63f0773sm5820320plr.289.2022.11.19.08.47.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Nov 2022 08:47:59 -0800 (PST) Message-ID: Date: Sat, 19 Nov 2022 09:47:58 -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: Palmer Dabbelt Cc: philipp.tomsich@vrull.eu, gcc-patches@gcc.gnu.org, Vineet Gupta , Kito Cheng , jlaw@ventanamicro.com, christoph.muellner@vrull.eu References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,BODY_8BITS,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/17/22 21:53, Palmer Dabbelt wrote: > On Thu, 17 Nov 2022 14:44:31 PST (-0800), jeffreyalaw@gmail.com wrote: >> >> 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. > > I don't really understand the middle-end issues here (if there are > any?), but I'm pretty sure code like this has passed by a few times > before and we've yet to find a reliable way to optimize these cases.  > There's a bunch of patterns where knowing the XLEN-extension of > shorter values would let us generate better code, but there's also > cases where we'd generate worse code by ensure any extension scheme is > followed. It's not really the extension scheme, though that is a subset of the concerns in this space.  Essentially we have to be 100% sure that the bits outside of the branch mode (QI/HI/SI) and XLEN are zero, it's not just the sign bit.  This becomes even more of a concern as we exploit the bitmanip extensions more aggressively. The SUBREG check is supposed to avoid that problem, but I'm not convinced it's sufficient. Philipp claims that PROMOTE_MODE plus WORD_REGISTER_OPERATIONS is sufficient here, but I'm not sure that's the case.   He's digging out the rationale from some internal archives which we'll dig into once he finds it. I'd be happy to be proved wrong :-) jeff