From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id D5F783858D38 for ; Fri, 14 Oct 2022 20:31:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D5F783858D38 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-x1029.google.com with SMTP id p3-20020a17090a284300b0020a85fa3ffcso8951607pjf.2 for ; Fri, 14 Oct 2022 13:31:25 -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=w8S+hjmt7nSUPe2ZJMXE47drQt1EklCvvMgHiA+oI6o=; b=A4FMnpRzjRDm9sUAJMst7LXqH/Pyle8+g2UzCyjA3HctLo4Kl3W/ouGSZMpCP6M4NY iQOs4966tH2WjKw5BPgXbGUIzr6tSaQaQy5PoZNPgKGH+IEqVxdEDL1X2U5/aB52MaSV hB9qzpiY2CKSfRl7PcY7HVk5ZOuVHnkJm5iRfs4h5bZI12jvurURX7UI79fnlXUrDpqo RoO6Rb1W0OnPQpJujxwAm44DGgy4LEODRQ5uI8Kj2YAz/oe+lXbZzHZGCaUA6qphgQrV 5G5mKkIVJ2MHeamVdJ2v2IgaTiETEutzIJIgkLAb7f/iFzuB24t065OUqWjmSYvofVsz t0tg== 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=w8S+hjmt7nSUPe2ZJMXE47drQt1EklCvvMgHiA+oI6o=; b=DS3CVKZMyxOUnENeIV2TlLNgAz39J9BjKTdX6ufvXUdXI3B5eXF0o+MctdQTt0QrXS o+EExm546EL11kui/pH4Xig5pjRZ1EJXDDia8OMA0vnwJ3ZJQKvRTEflaaGsAyFm3lmN pC2H4GD3Ph7iUyNQZv/D7/tBoWJV7G4frxX6qdHt43zBg/imm5oVMV1z+P2k995aRoRh GXfctp/4m27lW/da+5HPg/MjHcCKj6AeYeL5VgwKDJR77rCn6hLkj2v3f8u31mxNkd/d NYlkzYuPPDXZXRHwGClSzzQvxSbQJUFMj2E049K08+z0Pmos0dqUdZcmhaORCGUpG4vm EirQ== X-Gm-Message-State: ACrzQf1zxTG1RLEm652YZ9AKGZBazvSu0BkAnDqgxv2YjPpreGg8l3mn Wr+q8od12KCqPx49S1TK6yLi0o+Pq+0= X-Google-Smtp-Source: AMsMyM4+mCS3ovM2F2Jk2/4wEKURGa9dv/HMNLfZko6NHZSXd8UmBVd5BcWlAZ9pTntITAqZcHtc/w== X-Received: by 2002:a17:903:32c4:b0:178:5206:b396 with SMTP id i4-20020a17090332c400b001785206b396mr6846231plr.99.1665779484567; Fri, 14 Oct 2022 13:31:24 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id u7-20020a170903124700b0017a1145eec7sm2107853plh.157.2022.10.14.13.31.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 13:31:24 -0700 (PDT) Message-ID: <367ff707-58ab-7bb1-79d0-1ad2d4fb9f1a@gmail.com> Date: Fri, 14 Oct 2022 14:31:23 -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> <01f501d8a133$56fee8e0$04fcbaa0$@nextmovesoftware.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 10/10/22 09:50, H.J. Lu via Gcc-patches wrote: > On Thu, Jul 28, 2022 at 5:40 AM Richard Sandiford via Gcc-patches > wrote: >> Seems this thread has become a bit heated, so I'll try to proceed >> with caution :-) >> >> In the below, I'll use "X-mode const_int" to mean "a const_int that >> is known from context to represent an X-mode value". Of course, >> the const_int itself always stores VOIDmode. >> >> "Roger Sayle" writes: >>> Hi Segher, >>> It's very important to distinguish the invariants that exist for the RTL >>> data structures as held in memory (rtx), vs. the use of "enum rtx_code"s, >>> "machine_mode"s and operands in the various processing functions >>> of the middle-end. >> FWIW, I agree this distinction is important, with the proviso (which >> I think you were also adding) that the code never loses track of what >> mode an rtx operand (stored in a variable) actually has/is being >> interpreted to have. >> >> In other words, the reason (zero_extend (const_int N)) is invalid is >> not that constant integers can't be extended in principle (of course >> they can). It's invalid because we've lost track of how many bits >> that N actually has. That problem doesn't apply in contexts where >> the operation is described using individual variables (rather than >> a single rtx) *provided that* one of those variables says what mode >> any potential const_ints actually represent. >> >>> Yes, it's very true that RTL integer constants don't specify a mode >>> (are VOIDmode), so therefore operations like ZERO_EXTEND or EQ >>> don't make sense with all constant operands. This is (one reason) >>> why constant-only operands are disallowed from RTL (data structures), >>> and why in APIs that perform/simplify these operations, the original >>> operand mode (of the const_int(s)) must be/is always passed as a >>> parameter. >>> >>> Hence, for say simplify_const_binary_operation, op0 and op1 can >>> both be const_int, as the mode argument specifies the mode of the >>> "code" operation. Likewise, in simplify_relational_operation, both >>> op0 and op1 may be CONST_INT as "cmp_mode" explicitly specifies >>> the mode that the operation is performed in and "mode" specifies >>> the mode of the result. >> And the mode argument to simplify_const_relational_operation specifies >> the mode of the operands, not the mode of the result. I.e. it specifies >> the modes of op0 and op1 rather than the mode that would be attached to >> the code in "(code:mode ...)" if an rtx were created with these parameters. >> >> That confused me when I saw the patch initially. Elsewhere in the >> file "mode" tends to be the mode of the result, in cases where the >> mode of the result can be different from the modes of the operands, >> so using it for the mode of the operands seems a bit confusing >> (not your fault of course). >> >> I still struggle with the idea of having CC-mode const_ints though >> (using the meaning of "CC-mode const_ints" above). I realise >> (compare (...) (const_int 0)) has been the norm "for ever", but here >> it feels like we're also blessing non-zero CC-mode const_ints. >> That raises the question of how many significant bits a CC-mode >> const_int actually has. Currently: >> >> ... For historical reasons, >> the size of a CC mode is four units. >> >> But treating CC-mode const_ints as having 32 significant bits is surely >> the wrong thing to do. >> >> So if we want to add more interpretation around CC modes, I think we >> should first clean up the representation to make the set of valid values >> more explicit. (Preferably without reusing const_int for constant values, >> but that's probably a losing battle :-)) >> >> Thanks, >> Richard > Here is a testcase to show that combine generates > > (set (reg:CCC 17 flags) > (ltu:SI (const_int 1 [1]) > (const_int 0 [0]))) > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 > > This new target hook handles it properly ANd does it work if you reject MODE_CC comparisons with two constants in simplify_const_relational_operation? I suspect it will work, but generate suboptimal code. jeff