From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by sourceware.org (Postfix) with ESMTPS id B06983858C52 for ; Fri, 14 Oct 2022 21:06:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B06983858C52 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-qt1-x82b.google.com with SMTP id a24so4470279qto.10 for ; Fri, 14 Oct 2022 14:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MeTI+ow5r84MydTMLPLwlpuAO7EbVRRrNw5QSeuCH5g=; b=Cwq9G0TPUi0i4HNLFtVoHOAy+4F4F2sp5h5mj2hKMy6bJ0csMVzgOMp1zlJwxXBvgm /pcrRWmjZ7BPVj9uuX6W+2I1WzQcjDYzAF7VaJYcjog3uR23i2zSMnPUnt8v08qK8tug JkHuy+/hcaCXtxqiqnGxgOyo04SwWghMSwrIkJKHf/SpJrDf2GrwDZLdTodRM1KqsDoD g504WprQxE4XqLaDpmdbX5Z8OUiBYhhy6VHoqwwtFRqGfS3mDrlrMW0NN4CqnMG2tNP0 kyeth20zVecchkZJSKDkDuSQll8fdWzsSSwxtg73qAZuF5RbPjMUVcPh6u5UNtPb5y7I We/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MeTI+ow5r84MydTMLPLwlpuAO7EbVRRrNw5QSeuCH5g=; b=6e6l/T7q8Pv1yLCtVe8IuLuXwMeDBxwHq2H5cjL+3oNG22ZCEtW9l0V/ZU/TWgDb9M BLNf0xXwTBBk27e6wvG3zetnzuzU+W/3pECiHjrU9BYGGM10mQL2BO46g3M78fUDCDqO Ez7B/aVK7WUR3pCO7omUGuwDsFTPFTjbhVGU+W3SsQqs988TJBqryDpiZ6+ThS+Rlbkp xG3mEWgwraxO7mz6Ci1RErjsvfbXgqPcQ3x3cKiNOqNY5Ofk5jdZssfYaNesu5Qn2kZJ kaDoFeq6mTvDaalDWY3oyl3W2ZyVQpNrNs4rQESbne4UHwsAEYlUC7gCISckeFw3y0VP O2Qw== X-Gm-Message-State: ACrzQf1c2S84yoQogWN0V5tOxloWzal6KIiPwvTuflWkBaMdZFNOg2Ru Tg4ZyuE6Au9akzsOTtNvGbKSK4IKwQ9z9yqvvWE= X-Google-Smtp-Source: AMsMyM61HNLJ7oF8wMRtUHHNYlDi0Vci+oDNwV5szqYua81GzFRtItPYJs4T4fjYQVLBnIh7a2/2itFBtJ49kBGFjMs= X-Received: by 2002:ac8:6794:0:b0:39c:d44e:3682 with SMTP id b20-20020ac86794000000b0039cd44e3682mr5799274qtp.437.1665781587946; Fri, 14 Oct 2022 14:06:27 -0700 (PDT) MIME-Version: 1.0 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> <367ff707-58ab-7bb1-79d0-1ad2d4fb9f1a@gmail.com> In-Reply-To: <367ff707-58ab-7bb1-79d0-1ad2d4fb9f1a@gmail.com> From: "H.J. Lu" Date: Fri, 14 Oct 2022 14:05:52 -0700 Message-ID: Subject: Re: [PATCH] Add new target hook: simplify_modecc_const. To: Jeff Law Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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 Fri, Oct 14, 2022 at 1:32 PM Jeff Law via Gcc-patches wrote: > > > 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. It doesn't work for (ltu:SI (const_int 1 [0x1]) (const_int 0 [0])) simplified from (ltu:SI (reg:CCC 17 flags) (const_int 0 [0])) When simplify_const_relational_operation returns NULL for MODE_CC comparison with two constants, combine will try it again with VOIDmode comparison with two constants. -- H.J.