From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id D08973858D38 for ; Fri, 14 Oct 2022 20:26:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D08973858D38 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-x632.google.com with SMTP id c24so5752734pls.9 for ; Fri, 14 Oct 2022 13:26:28 -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:message-id:reply-to; bh=DyZryicRvQzY1lcRkJLJcZqPsC0nqBsnznwKqmYubpY=; b=me5/i6ukeahNYKu6122NV/fefIF71jPUZ6IVWI1i/QWbSkU7ovqkgJHv0RXfiRMrw+ 6ukstPwVsk67ZHEfnVNFB1dgznEi9edwIu8Su+DwayDPbczFbbSICBsZZVFjS2FuQfWS uGTyMzXOINWStj2x6Su7jQ/+lqj8MsOt3A8Qlpy6MgCqGDGXnYJLPmBpQvv8VCCX7Vx7 mah5UNi5PzkR3cYYEArYmLO6mdtakQCbJ/Ms/QDtnB11xZZ2g/sb0qmOycv73MUba34s JncjdhtVEZ1Zy67ckuyq1IRuRw/Ledq5DCt3rv7IOycdi7nJ8e6nqIXLJYOxJcyxQTCL W9TQ== 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:message-id:reply-to; bh=DyZryicRvQzY1lcRkJLJcZqPsC0nqBsnznwKqmYubpY=; b=aWshDhzMAaYMUDcM+GUYq20REn1EPT2BT+591C8t6sEJJsksk564wyacHiGS/+657T KaEHNSBg32nHH29iOhHeLrrJZIr2C738uTlNBhZncR+uAm1qLfZr5piND9zuXjsWoHy6 ov0JN15dQwOgA8esZpN85X9t+t/PK37SNZTKzbQNNitYWYdEtP39XIVCWIs50fjF8fuh L9o3r5ZpXmC5jkU6pGz7yJR5w7sc0nAAt/N9r8Ug9OKsy1pGi/1t4k9lF29vFnpYzR/j Cicqgc8/AmdmBPN8zUFj53vkhiAhTB4I3uvrYDhA49VBlxN4vpYSeB2YJirTUXANm+OA Xf+w== X-Gm-Message-State: ACrzQf3MMusTevVUT3m7y0ynWWcMSzxrX0mVXD2aUjmuMIrvkDe6HDfC 6SEeUULAmUvTRfTURzhwG26GR3ci/LU= X-Google-Smtp-Source: AMsMyM5dqym4jXzZ4IzMhikobF7BCydl7astdmjgYAuNDC1WOMPYtNi6IDH8J1U4jq++JuDq1Wxo8Q== X-Received: by 2002:a17:90b:1e11:b0:20d:90b3:45a0 with SMTP id pg17-20020a17090b1e1100b0020d90b345a0mr16500446pjb.29.1665779187225; Fri, 14 Oct 2022 13:26:27 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id y16-20020a17090264d000b00176e6f553efsm2098503pli.84.2022.10.14.13.26.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 13:26:26 -0700 (PDT) Message-ID: Date: Fri, 14 Oct 2022 14:26:25 -0600 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] Add new target hook: simplify_modecc_const. Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <003601d89245$a86f8830$f94e9890$@nextmovesoftware.com> <20220707223833.GA25951@gate.crashing.org> <00fa01d8a0e9$0efdfc60$2cf9f520$@nextmovesoftware.com> <20220726174451.GA25951@gate.crashing.org> From: Jeff Law In-Reply-To: <20220726174451.GA25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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 7/26/22 11:44, Segher Boessenkool wrote: > Hi! > > On Tue, Jul 26, 2022 at 01:13:02PM +0100, Roger Sayle wrote: >> This patch is a major revision of the patch I originally proposed here: >> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598040.html >> >> The primary motivation of this patch is to avoid incorrect optimization >> of MODE_CC comparisons in simplify_const_relational_operation when/if a >> backend represents the (known) contents of a MODE_CC register using a >> CONST_INT. In such cases, the RTL optimizers don't know the semantics >> of this integer value, so shouldn't change anything (i.e. should return >> NULL_RTX from simplify_const_relational_operation). > This is invalid RTL. What would (set (reg:CC) (const_int 0)) mean, > for example? If this was valid it would make most existing code using > CC modes do essentially random things :-( I'm not sure why you're claiming (set (reg:CC) (const_int 0)) is invalid.  I'm not aware of anything that would make it invalid -- but generic code doesn't really know how to interpret what it means.  While I have concerns in that space, they're pretty obscure and likely don't occur in practice due to the use of CC modes. Not the interpretation of the underlying bits in the condition code is already defined as machine specific: @findex CCmode @item CCmode ``Condition Code'' mode represents the value of a condition code, which is a machine-specific set of bits used to represent the result of a comparison operation.  Other machine-specific modes may also be used for the condition code.  (@pxref{Condition Code}). Roger's patch does introduce special meaning to a relational operators in MODE_CC with two constants and I think that's really what you're concerned with and I would share a similar concern. Though perhaps not as severe as yours given how special MODE_CC has to be in many contexts. I suspect we could probably all agree that rejecting a MODE_CC relational in simplify_const_relational_operation which would have been the minimal change to address the bug Roger is trying to fix.   I wouldn't be surprised if he started with that, then realized "hey, if we could ask the backend what 0 or 1 means for CC, then we could actually optimize this away completely and here we are... > Comparing two integer constants is invalid RTL *in all contexts*. The > items compared do not have a mode! From rtl.texi: > A @code{compare} specifying two @code{VOIDmode} constants is not valid > since there is no way to know in what mode the comparison is to be > performed; the comparison must either be folded during the compilation > or the first operand must be loaded into a register while its mode is > still known. And I think the counter argument is that MODE_CC has enough special properties that it could be an exception to this rule. I'm not sure I'm ready to say, yes we should make this change, but I'm also not ready to summarily reject the change. jeff